Timelock को ऐसा नियम समझिए जो कहता है, “इस रास्ते से, कुछ समय बाद ही।” यह किसी ब्लॉक की ऊँचाई, यानी चेन में उसकी क्रम संख्या, चेन से निकाले गए समय या खास आउटपुट के कन्फ़र्म होने के बाद की प्रतीक्षा पर आधारित हो सकता है। आउटपुट ऐसी रकम है जिसके नियम बताते हैं कि कौन, किन शर्तों पर उसे खर्च कर सकता है। इंतज़ार हस्ताक्षर या दूसरी ज़रूरतों की जगह नहीं लेता और अपने आप पैसे नहीं भेजता। यह भी देखना ज़रूरी है कि समय सिर्फ़ एक तैयार ट्रांज़ैक्शन को रोकता है या खुद पैसे खर्च करने के नियमों से लागू होता है।
Anna और Pavel साझा पैसे ऐसे रख सकते हैं कि दोनों मिलकर उन्हें कभी भी खर्च कर सकें, लेकिन Anna अकेले एक तय प्रतीक्षा के बाद ही खर्च कर सके। अगर Pavel जवाब देना बंद कर दे, तो देर से खुलने वाली शाखा पहले से तय वापसी का रास्ता देती है। शाखा का मतलब यहाँ खर्च करने का एक अनुमत तरीका है; हर तरीके की शर्तें अलग हो सकती हैं। इसलिए लॉक को सारे रास्ते एक साथ बंद करना ज़रूरी नहीं है। नियम आउटपुट बनते समय ही उसका हिस्सा होने चाहिए। बाद में सामान्य वॉलेट में “एक हफ़्ते बाद खोलना” लिख देना काफ़ी नहीं है। इंतज़ार के बाद भी Anna को संबंधित कुंजी और वैध ट्रांज़ैक्शन बनाने की जानकारी चाहिए। Timelock पहुँच नियंत्रित करता है, खोई हुई कुंजियाँ वापस नहीं लाता। [3]
Absolute यानी निरपेक्ष लॉक एक तय सीमा बताता है, जो ट्रांज़ैक्शन के nLockTime नाम के फ़ील्ड में दर्ज होती है। अगर ट्रांज़ैक्शन का प्रभावी nLockTime ब्लॉक ऊँचाई 1 000 000 है, तो यह शर्त पहली बार ब्लॉक 1 000 001 में पूरी हो सकती है; बराबर होना अभी काफ़ी नहीं है। Relative यानी सापेक्ष लॉक खर्च होने वाले आउटपुट की पुष्टि से देरी गिनता है। अगर Anna का आउटपुट ब्लॉक 1 000 000 में बना और संबंधित शाखा में 6 ब्लॉक की देरी चाहिए, तो उसे खर्च करने की यह शर्त सबसे पहले ब्लॉक 1 000 006 में पूरी होगी। ये उदाहरण के अंक हैं, नेटवर्क की वर्तमान ऊँचाई नहीं। हस्ताक्षरों, दूसरे इनपुट और अतिरिक्त लॉक की शर्तें फिर भी लागू हैं। छह ब्लॉक भी ठीक एक घंटा नहीं हैं; ब्लॉक अनियमित अंतराल पर आते हैं। सापेक्ष प्रतीक्षा वॉलेट बनाने या Anna के पैसे इस्तेमाल करने का निर्णय लेने से शुरू नहीं होती। [1] [2] [5]
मान लीजिए Anna की ज़रूरी प्रतीक्षा अभी पूरी हुई। नेटवर्क उसकी ओर से काम शुरू नहीं करेगा। किसी को अब भी ट्रांज़ैक्शन बनानी या तैयार वाली इस्तेमाल करनी होगी, हस्ताक्षर देने होंगे, फ़ीस चुकानी होगी और उसे नेटवर्क तक पहुँचाना होगा। तभी माइनर उसे ब्लॉक में डाल सकता है। पूरा हुआ Timelock एक पूरी हुई शर्त है, जगह का आरक्षण या अपने आप होने वाला ट्रांसफ़र नहीं। आम तौर पर यह खर्च की संभावना शुरू होने का समय तय करता है, अपने आप खत्म होने का समय नहीं। चेन के पुनर्गठन में उसका एक हिस्सा दूसरी वैध शाखा से बदल जाता है। इससे आउटपुट की पुष्टि और सापेक्ष देरी की गणना बदल सकती है। अपना ढाँचा बनाते समय सभी शाखाएँ, वॉलेट का समर्थन और कुंजियों के साथ खर्च के नियमों का बैकअप पहले जाँचना चाहिए; समय गलत तय की गई शर्त नहीं सुधारता। [2] [5]
समय आधारित शर्तें Median Time Past, संक्षेप में MTP, का उपयोग करती हैं। जाँचे जा रहे ब्लॉक के लिए यह पिछले ब्लॉक तक के अंतिम 11 ब्लॉकों के timestamps की माध्यिका है। उनके समय क्रम में लगाइए और बीच वाला, छठा चुनिए: यही माध्यिका है, अंकगणितीय औसत नहीं। BIP113 यह नियम बताता है और Bitcoin Core गणना के लिए GetMedianTimePast इस्तेमाल करता है। इसलिए निर्णायक समय न Anna के फ़ोन का वर्तमान समय है, न प्रस्तावित ब्लॉक का अपना timestamp। कैलेंडर की आधी रात वही क्षण हो, जब लॉक पूरा हो, यह ज़रूरी नहीं। ऊँचाई वाले लॉक ब्लॉकों का इंतज़ार करते हैं, सेकंड की उलटी गिनती नहीं। [4]
अब दस्तावेज़ों के चार नाम अलग समझ सकते हैं। nLockTime पूरी ट्रांज़ैक्शन का फ़ील्ड है, जो निरपेक्ष सीमा बताता है। इनपुट का nSequence, BIP68 के अनुसार सापेक्ष देरी रखता है। लेकिन अकेला nLockTime किसी UTXO, यानी अभी तक न खर्च हुए आउटपुट, को अलग सेटिंग वाली दूसरी ट्रांज़ैक्शन से बंद नहीं करता। खर्च का अधिकार रखने वाला ऐसी दूसरी ट्रांज़ैक्शन बना सकता है, अगर आउटपुट के नियम उसे न रोकें। Bitcoin Script वह भाषा है जिसमें खर्च के ये नियम लिखे जाते हैं। OP_CHECKLOCKTIMEVERIFY, या BIP65 का CLTV, इस्तेमाल की गई शाखा में संबंधित निरपेक्ष सेटिंग माँगता है। OP_CHECKSEQUENCEVERIFY, यानी BIP112 का CSV, सापेक्ष सेटिंग जाँचता है, जबकि असली देरी BIP68 लागू करता है। CLTV और CSV न पैसे भेजते हैं, न गायब हस्ताक्षर जोड़ते हैं। दूसरी अनुमत शाखा अलग शर्तों पर इस्तेमाल हो सकती है। [1] [2] [3]
आगे के भाग तकनीकी संदर्भ हैं। फ़ील्ड ट्रांज़ैक्शन में सहेजी जानकारी है; इनपुट खर्च होने वाले आउटपुट को बताता है। हर इनपुट का nSequence होता है। खास मान nLockTime का असर बंद कर सकता है, इसलिए सिर्फ़ तारीख भरना काफ़ी नहीं है। nLockTime एक 32-बिट फ़ील्ड है जो ऋणात्मक संख्याएँ नहीं रखता; शून्य निरपेक्ष समय शर्त बंद करता है। यदि सभी इनपुट 0xffffffff मान वाला SEQUENCE_FINAL उपयोग करते हैं, तो अधूरा nLockTime अनदेखा किया जाता है। प्रभावी निरपेक्ष प्रतिबंध के लिए कम से कम एक इनपुट की nSequence अलग होनी चाहिए। मूल्यांकन उस खास लेनदेन का होता है, उसके इनपुट को हमेशा के लिए जमाने का नहीं। [5] [7]
एक ही फ़ील्ड दो अलग बातें बता सकता है, जिन्हें संख्यात्मक सीमा अलग करती है। Unix timestamp, UTC में 1970 की शुरुआत से गुज़रे सेकंड में समय लिखता है। संभावित ब्लॉक वह है जिसमें जाँची जा रही ट्रांज़ैक्शन शामिल की जानी है। LOCKTIME_THRESHOLD का मान 500000000 है। इससे कम nLockTime ब्लॉक ऊँचाई है; बराबर या अधिक मान Unix timestamp है। निरपेक्ष जाँच चालू होने पर nLockTime संभावित ब्लॉक की ऊँचाई या संबंधित MTP से सख्ती से कम होना चाहिए। बराबरी पर्याप्त नहीं है; यह राशि, औसत ऊँचाई या प्रोटोकॉल सक्रिय होने की तारीख नहीं है। [5] [8]
Operand कमांड को दिया गया मान है; opcode खुद Script का कमांड है। CLTV शाखा में रखी माँग की तुलना ट्रांज़ैक्शन की सेटिंग से करता है। चेन पर्याप्त आगे बढ़ी या नहीं, यह अलग जाँच तय करती है। यह आज की तारीख को एक अंक से मिलाने भर की बात नहीं है। OP_CHECKLOCKTIMEVERIFY के लिए गैर-ऋणात्मक operand, nLockTime जैसा ही ऊँचाई/समय प्रकार और nLockTime से अधिक न होने वाला operand जरूरी है। संबंधित खर्च इनपुट की nSequence 0xffffffff नहीं हो सकती। Opcode सीधे घड़ी या चेन ऊँचाई नहीं पढ़ता; समय संबंधी वैधता के मूल्यांकन में लेनदेन की सेटिंग अलग से जाँची जाती है। Script की अन्य शर्तें भी जरूरी रहती हैं। [1] [6]
nSequence के अंक में प्रतीक्षा की अवधि और उसका अर्थ तय करने वाले स्विच दोनों होते हैं। बिट इस लिखावट में शून्य या एक है; उसे सेट करने से कोई विकल्प चालू हो सकता है। नीचे के बिट-स्थान तकनीकी प्रारूप का हिस्सा हैं, पुष्टि की गिनती नहीं। वर्ज़न 2 या उससे ऊपर के लेनदेन में BIP68 उन इनपुट पर सापेक्ष शर्त लगाता है जिनका बिट 31 सेट नहीं है। निचले 16 बिट देरी तय करते हैं; बिट 22 सेट होने पर इकाई 512 सेकंड होती है, अन्यथा ब्लॉक। ब्लॉक देरी खर्च होने वाले आउटपुट की पुष्टि की ऊँचाई से गिनी जाती है। समय देरी उस पुष्टि से पिछले ब्लॉक के MTP से संभावित ब्लॉक के पिछले MTP तक मापी जाती है। यह वॉलेट में लेनदेन बनाने के बाद का समय नहीं है। [2] [5]
CSV सापेक्ष प्रतीक्षा के लिए ऐसी ही जाँच करता है। Mask संबंधित nSequence बिट चुनता है और disable flag बंद करने का स्विच है। Lightning Network भुगतान चैनलों का नेटवर्क है। इनमें भागीदार साथ में लॉक की गई रकम का सहमत बँटवारा अपडेट करते हैं। अगर कोई पुरानी, रद्द की जा चुकी स्थिति प्रकाशित करे, तो यह देरी दूसरे पक्ष को प्रतिक्रिया देने का समय देती है। Commitment transaction रकम का बँटवारा दर्ज करती है; revocation key से दूसरा पक्ष रद्द संस्करण का संबंधित आउटपुट दंड वाली शाखा के ज़रिए खर्च कर सकता है। सक्रिय गैर-ऋणात्मक operand वाला OP_CHECKSEQUENCEVERIFY कम से कम वर्ज़न 2, इनपुट का disable flag बंद, समान देरी प्रकार और मास्क लगाने के बाद nSequence का पर्याप्त बड़ा मान माँगता है। वास्तविक उम्र BIP68 अलग से लागू करता है। CSV विलंबित पुनर्प्राप्ति शाखा की अनुमति देता है। Lightning के to_local आउटपुट में to_self_delay, commitment transaction के मालिक को सीमित करता है; सही revocation key वाला दूसरा पक्ष इस देरी के बिना दंड शाखा उपयोग कर सकता है। [3] [9]
लगभग एक जैसे दो अंकों के असर अलग हो सकते हैं। नीचे 0x से शुरू मान सोलह-आधार वाली संख्या पद्धति में हैं। NOP ऐसा निर्देश है जो यहाँ समय की अतिरिक्त रोक नहीं लगाता। यह भी ज़रूरी है कि स्विच ट्रांज़ैक्शन के इनपुट में है या CSV को दिए गए मान में। बिट 31, SEQUENCE_LOCKTIME_DISABLE_FLAG है और केवल उस इनपुट के लिए BIP68 की सापेक्ष व्याख्या बंद करता है। 0xfffffffe में यह बिट है, लेकिन वह SEQUENCE_FINAL नहीं है: उससे प्रभावी nLockTime और CLTV संभव हैं। 0xffffffff, final है। disable flag सेट वाला गैर-ऋणात्मक CSV operand, NOP जैसा व्यवहार करता है; लेकिन इनपुट में यह flag सेट हो तो सक्रिय CSV की माँग पूरी नहीं होती। इन दोनों स्थितियों को मिलाना नहीं चाहिए। [3] [7]
RPC अपने नोड से काम कराने का कमांड है। नोड वह प्रोग्राम है जो बिटकॉइन के ब्लॉक और ट्रांज़ैक्शन की जाँच करता है। Decoding केवल सहेजे डेटा को पढ़ने लायक सूची बनाती है; टेस्ट कमांड फिर देखता है कि खास हस्ताक्षरित ट्रांज़ैक्शन जाँच में पास होगी या नहीं। Mempool उस नोड की स्थानीय प्रतीक्षारत ट्रांज़ैक्शन सूची है। Core 31 का decoderawtransaction RPC, version, locktime और हर इनपुट का sequence दिखाता है। CLTV/CSV के लिए वास्तव में प्रयुक्त Script और खर्च होने वाले आउटपुट को जाँचें; केवल decoding वैधता का प्रमाण नहीं है। testmempoolaccept RPC हस्ताक्षरित उम्मीदवार को वर्तमान चेन, बिटकॉइन की वैधता के नियमों और नोड के स्थानीय ट्रांज़ैक्शन स्वीकारने के नियमों के अनुसार परखता है, mempool में स्वीकार या प्रसारित नहीं करता। allowed और अस्वीकृति का कारण जाँचें; सफलता भविष्य की पुष्टि का वादा नहीं है। [10] [11] [12]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें CLTV, CSV, Lightning Network, Payment Channel, लेनदेन, Bitcoin Script. इस प्रविष्टि का उल्लेख यहाँ भी है पुष्टि, Bitcoin Script, HTLC, CLTV.