Peter Todd

मान लीजिए आपको साबित करना है कि किसी अनुबंध का खास संस्करण विवाद शुरू होने से पहले मौजूद था। Peter Todd से जुड़ा OpenTimestamps प्रोजेक्ट इसी तरह की ज़रूरत में मदद करता है। 2016 की उनकी ऐतिहासिक घोषणा में सार्वजनिक परीक्षण संस्करण पेश किया गया और विकास तथा परीक्षण के लिए Riccardo Casatta को धन्यवाद दिया गया। यह उस समय के सहयोग का रिकॉर्ड है, न कि यह दावा कि प्रोजेक्ट आज भी प्रयोग की अवस्था में है। Todd ने भविष्य में धन खर्च करने की शर्तों और पुष्टि की प्रतीक्षा कर रहे भुगतानों पर भी काम किया। पहले इन्हीं दो क्षेत्रों को समझते हैं। [1]

Todd के BIP 65 ने OP_CHECKLOCKTIMEVERIFY, संक्षेप में CLTV, प्रस्तुत किया। यह निर्देश किसी खास खर्च-मार्ग को एक ब्लॉक ऊँचाई या समय-सीमा तक पहुँचने की शर्त से बाँध सकता है। साझा बचत तक पहुँचने का ऐसा वैकल्पिक रास्ता सोचिए जिसे प्राप्तकर्ता बाद में ही इस्तेमाल कर सके। तब तक समय की शर्त उस रास्ते को रोकती है। शर्त पूरी होने पर कॉइन खुद नहीं भेजे जाते: वैध लेन-देन बनाना और हस्ताक्षर जैसी बाकी ज़रूरतें पूरी करना अभी भी आवश्यक है। यदि खर्च का दूसरा रास्ता है तो उसकी अपनी शर्तें होंगी; यह लॉक हर तरीके पर लागू हो, ऐसा ज़रूरी नहीं। [2]

समय-आधारित लॉक केवल वॉलेट में दिखाई दे रही घड़ी को नहीं देखता। BIP 65, खर्च की शर्तें तय करने वाले निर्देशों यानी स्क्रिप्ट और लेन-देन के nLockTime फ़ील्ड का संबंध जाँचता है। दोनों को एक ही प्रकार की सीमा इस्तेमाल करनी होती है: ब्लॉक ऊँचाई या समय। इनपुट का nSequence फ़ील्ड भी ऐसा अंतिम मान नहीं रख सकता जो यह जाँच निष्प्रभावी कर दे। यह एक तय सीमा है, पुष्टि के बाद से आउटपुट की सापेक्ष उम्र नहीं। शर्तें पूरी होने से किसी खास सेकंड में ब्लॉक में शामिल होना तय नहीं होता; माइनर को अभी भी लेन-देन वैध ब्लॉक में जोड़ना होता है। [2]

प्रसारित लेन-देन mempool में रुका रह सकता है। यह किसी नोड के पास मौजूद अपुष्ट लेन-देन का संग्रह है। फ़ीस बढ़ने पर भेजने वाला प्रतिस्थापन लेन-देन के ज़रिए अधिक फ़ीस देना चाह सकता है। David A. Harding और Peter Todd ने BIP 125 में मूल opt-in नियम बताए, जिनमें बदलने की अनुमति का संकेत दिया जाता था। संकेत nSequence से मिल सकता था या किसी अपुष्ट पूर्ववर्ती लेन-देन से विरासत में आ सकता था, जिसका आउटपुट यह भुगतान खर्च करता है। इसलिए आपसी निर्भरताएँ भी मायने रखती थीं। अधिक फ़ीस मदद कर सकती है, लेकिन तत्काल पुष्टि की गारंटी नहीं है। [3]

mempool में प्रतिस्थापन से वह लेन-देन बदलता है जिसे नोड पुष्टि के उम्मीदवार के रूप में रखता है। इससे पुष्ट इतिहास दोबारा नहीं लिखा जाता। BIP 125 एक ऐतिहासिक opt-in नीति भी बताता है, हर प्रोग्राम के लिए अटल नियम नहीं। बाद के Bitcoin Core संस्करणों ने उस संकेत के बिना प्रतिस्थापन को सामान्य व्यवहार बना दिया, लेकिन नए लेन-देन को स्वीकार करने की शर्तें बनी रहीं। प्राप्तकर्ता के लिए बात सीधी है: संकेत न होना अपने आप में भुगतान के अंतिम होने का प्रमाण नहीं। इसी तरह वॉलेट में “भेजा गया” दिखना, पुष्ट ब्लॉक में शामिल होने के बराबर नहीं है। [3] [6]

अनुबंध पर लौटते हैं। OpenTimestamps ऐसा प्रमाण बनाता है जिसे जाँचकर दिखाया जा सके कि खास डेटा प्रमाणित समय-सीमा से पहले मौजूद था। इसमें hash, यानी सामग्री की छोटी डिजिटल पहचान, और Bitcoin से जुड़ा प्रमाण इस्तेमाल होता है। दस्तावेज़ बदलने पर जाँच में अलग पहचान मिलेगी। लेकिन टाइमस्टैम्प अकेले लेखक, सामग्री की सच्चाई या बनने के ठीक क्षण को प्रमाणित नहीं करता। कोई झूठा विवरण भी पहले से लिखकर उसका टाइमस्टैम्प ले सकता है। प्रमाण यह सीमित करता है कि डेटा अधिकतम कितनी देर से बना हो सकता है; यह नहीं बताता कि उससे पहले वह कितने समय से मौजूद था। [1] [4]

OpenTimestamps क्लाइंट दस्तावेज़ स्वयं कैलेंडर सर्वरों को नहीं भेजता। वह उसकी डिजिटल पहचान को एक यादृच्छिक मान के साथ संसाधित करता है, ताकि प्राप्त डेटा से सर्वर सामग्री का अनुमान न लगा सके। यहाँ कैलेंडर एक सेवा है जो अनुरोध जुटाती और उन्हें Bitcoin से जोड़ने में मदद करती है। सामग्री की गोपनीयता पूर्ण गुमनामी नहीं है: पास-पास के समय या साथ बने प्रमाण अनुरोधों के बीच संबंध दिखा सकते हैं। बनी हुई .ots फ़ाइल दस्तावेज़ का बैकअप नहीं है। उसे बिल्कुल उसी मूल फ़ाइल के साथ रखें; डिजिटल पहचान से खोया पाठ वापस नहीं मिलता और संपादित प्रति अलग डेटा है। [5]

नया टाइमस्टैम्प अभी किसी पुष्ट Bitcoin ब्लॉक से जुड़ा न भी हो सकता है। इसलिए केवल .ots फ़ाइल होना काम पूरा होने का प्रमाण नहीं है। OpenTimestamps क्लाइंट लंबित प्रमाण और ब्लॉक तक पूरा मार्ग रखने वाले प्रमाण में अंतर करता है। ots upgrade आदेश, पूरक जानकारी उपलब्ध होने पर उसे डाउनलोड करके सहेज सकता है; वह ब्लॉक की माइनिंग करवाने के लिए बाध्य नहीं कर सकता। फिर मूल डेटा और Bitcoin शृंखला के आधार पर प्रमाण जाँचना ज़रूरी है। प्रतीक्षारत भुगतान की तरह यहाँ भी वास्तविक स्थिति मायने रखती है, केवल फ़ाइल या सूचना का दिखाई देना नहीं। [5]