CLTV, Bitcoin Script के OP_CHECKLOCKTIMEVERIFY निर्देश का संक्षिप्त नाम है। यह खर्च को एक तय ब्लॉक ऊँचाई या समय की सीमा से जोड़ता है। सीमा पूरी होने के बाद भी बाकी शर्तें पूरी करनी होती हैं, लेनदेन बनाना होता है और उसे ब्लॉक में शामिल होना होता है। पैसा अपने आप नहीं जाता।
अन्ना ऐसी व्यवस्था बना रही हैं जिसमें रोज़मर्रा के भुगतान को वह और पीटर मिलकर मंज़ूरी दें। किसी के लंबे समय तक उपलब्ध न होने पर वह एक वैकल्पिक रास्ता भी चाहती हैं, जिसका इस्तेमाल चुनी हुई सीमा के बाद ही हो सके। CLTV इस समय की शर्त को स्क्रिप्ट में रख सकता है, यानी पहले मिले कॉइन खर्च करने के नियमों में। अकेला nLockTime फ़ील्ड केवल एक खास लेनदेन को टालता। CLTV कम सीमा वाला नया लेनदेन बनाकर इस रास्ते की शर्त से बचने नहीं देता। दूसरी शाखाओं के नियम फिर भी अलग हो सकते हैं। [1] [5]
CLTV मालिक को पहचानता नहीं और पैसा भेजता नहीं। अगर रिकवरी रास्ते में अन्ना के हस्ताक्षर चाहिए, तो समय की शर्त पूरी होने के बाद भी उन्हें वे देने होंगे। निजी कुंजी एक गुप्त संख्यात्मक मान है, जिससे ऐसा हस्ताक्षर बनाया जाता है। समय बीतने से खोई हुई निजी कुंजी वापस नहीं आती। कॉइन अपने आप दूसरे पते पर भी नहीं पहुँचते: किसी को वैध लेनदेन तैयार करना, उस पर हस्ताक्षर करना और उसे नेटवर्क में प्रसारित करना होगा। अगर दूसरी शाखा पहले खर्च की अनुमति देती है, तो रिकवरी शाखा का समय-ताला उसे अपने आप सीमित नहीं करता। [1]
ब्लॉक लेनदेन का एक समूह है, जो साझा इतिहास में जोड़ा जाता है। CLTV पहले से तय बिंदु से जुड़ी शर्त के लिए है, न कि “ये कॉइन मिलने के बाद इतने ब्लॉक इंतज़ार करो” जैसी माँग के लिए। दूसरा काम CSV और सापेक्ष ताले के नियम BIP 68 करते हैं। उसमें खास आउटपुट की पुष्टि का समय मायने रखता है। आउटपुट यानी पहले मिली रकम और उसे खर्च करने की शर्तें। कोई भी तरीका कैलेंडर की सटीक तारीख की गारंटी नहीं देता। माइनिंग की गति बदलती है और चेन के पुनर्गठन से पुष्टि वाला इतिहास बदल सकता है। पुनर्गठन में नेटवर्क चेन की दूसरी वैध शाखा अपनाता है, जिससे पुराने ब्लॉक इतिहास का एक हिस्सा बदल जाता है। [1] [7] [8] [9]
CLTV दो तरह के मान पहचानता है। 500000000 से कम मान ब्लॉक की ऊँचाई, यानी चेन में उसका स्थान बताता है। इस सीमा से शुरू होने वाले मान टाइमस्टैम्प होते हैं, यानी अंकों में लिखा समय। स्क्रिप्ट की शर्त और खर्च करने वाले लेनदेन के nLockTime का प्रकार एक होना चाहिए। केवल यह देखना काफी नहीं कि कौन-सा नंबर बड़ा है: ब्लॉक का स्थान और समय एक ही अर्थ नहीं रखते। [1] [3] [5]
Full Node वह नोड है जो नियमों की जाँच खुद करता है। वह स्क्रिप्ट की गैर-ऋणात्मक सीमा की तुलना लेनदेन के निरपेक्ष nLockTime से करता है। सीमा nLockTime से बड़ी नहीं हो सकती; इस जाँच में बराबरी स्वीकार है। साथ ही, लेनदेन को किसी खास ब्लॉक में शामिल करने के नियम भी पूरे होने चाहिए। CLTV आपके कंप्यूटर की घड़ी नहीं पढ़ता और प्रोग्राम को सुबह तक रोककर नहीं रखता। जाँच असफल हो तो उस रास्ते से खर्च करने का प्रयास अमान्य है। [1] [3] [4]
लेनदेन का इनपुट बताता है कि पहले मिले कौन-से कॉइन खर्च हो रहे हैं। उसके फ़ील्ड में nSequence भी है। CLTV जिस इनपुट को जाँचता है, उसमें इसका मान 0xffffffff नहीं हो सकता। यह अंतिम सीक्वेंस का विशेष मान है। सभी इनपुट में यही मान हो तो nLockTime बंद किया जा सकता है। CLTV संबंधित इनपुट को गैर-अंतिम रखने की माँग करके इसे रोकता है। इससे कोई खास सापेक्ष इंतज़ार अपने आप तय नहीं होता; वह दूसरे नियमों का काम है। [1] [3] [4]
मान लीजिए लेनदेन का nLockTime 900000 है और इनपुट गैर-अंतिम है। इस समय-शर्त के हिसाब से सबसे पहला संभव ब्लॉक 900001 है। शामिल होने के लिए nLockTime का संभावित ब्लॉक की ऊँचाई से सख्ती से छोटा होना ज़रूरी है। इसलिए ब्लॉक 900000 काफी नहीं, भले ही CLTV के भीतर की तुलना ने बराबरी स्वीकार कर ली हो। यहाँ “अंतिमता” का अर्थ शामिल होने की पात्रता है, भुगतान का अपरिवर्तनीय होना नहीं। शुल्क, बाकी शर्तें और माइनर का चुनाव पुष्टि में और देरी कर सकते हैं। [4]
टाइमस्टैम्प के लिए BIP 113 पिछले ब्लॉक का Median Time Past इस्तेमाल करता है। यह हाल के अधिकतम 11 ब्लॉक के टाइमस्टैम्प क्रम में रखने पर बीच का मान है, न आपकी घड़ी और न अभी माइन हो रहे ब्लॉक का समय। समय वाला nLockTime इस मान से सख्ती से छोटा होना चाहिए। इसलिए स्थानीय दोपहर के ठीक समय कॉइन खर्च हो सकने का वादा नहीं किया जा सकता। इस शर्त को नेटवर्क जाँच सकता है, लेकिन यह भुगतान की सटीक समय-सारणी नहीं है। [2] [4]
स्क्रिप्ट चलने के दौरान स्टैक का इस्तेमाल करती है, यानी डेटा रखने का एक कार्यक्षेत्र जहाँ चीज़ें एक के ऊपर एक रखी जाती हैं। CLTV समय वाले आर्ग्युमेंट को जाँचता है, हटाता नहीं। इसलिए सरल रूपरेखा में OP_CHECKLOCKTIMEVERIFY के बाद OP_DROP उसे हटाता है; फिर सार्वजनिक कुंजी रखी जाती है और OP_CHECKSIG हस्ताक्षर जाँचता है। सार्वजनिक कुंजी से हस्ताक्षर की जाँच की जाती है; उसे गुप्त रखना ज़रूरी नहीं है। यह निर्देशों की भूमिका समझाने वाला उदाहरण है, पैसा लॉक करने का तैयार नुस्खा नहीं। स्क्रिप्ट का संस्करण, शुरुआती डेटा और खर्च के बाकी सभी रास्ते भी सही होने चाहिए। [1] [3]
BIP 65 ने CLTV को soft fork के रूप में शुरू किया: नियम कड़े किए गए और पुराने OP_NOP2 की जगह यह निर्देश आया। इसलिए यह केवल भविष्य की सुविधा का प्रस्ताव नहीं है। फिर भी पूरी बनावट जाँचनी होगी: सीमा का प्रकार, nLockTime, nSequence, हस्ताक्षर और वैकल्पिक शाखाएँ। तकनीकी विवरण Bitcoin Core v29.0 और दिए गए विनिर्देशों में मिलते हैं। आम उपयोगकर्ता के लिए मुख्य बात है कि सीमा से पहले और बाद में कौन पैसा खर्च कर सकता है, और क्या रिकवरी के विकल्प समझ में आते हैं। [1] [3] [6] [10]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें CSV, Opcode, Timelock, Bitcoin Script, Bitcoin, Full Node. इस प्रविष्टि का उल्लेख यहाँ भी है Timelock, HTLC, Opcode, CSV.