OP_CHECKTEMPLATEVERIFY

आना धन तैयार रखना चाहती है जिसे बाद में पीटर और ईवा के बीच बाँटा जाएगा। वह पैसे रखने वाले किसी व्यक्ति के वादे पर ही निर्भर नहीं रहना चाहती। Bitcoin में बिना खर्च हुआ धन लेनदेन के आउटपुट, यानी UTXO, के रूप में दर्ज होता है; हर आउटपुट में रकम और उसे उपयोग करने की शर्तें होती हैं। CTV उन शर्तों में बँटवारे की खास योजना जोड़ सकता है। आउटपुट खर्च होते समय नोड, यानी नेटवर्क के नियम जाँचने वाले प्रोग्राम, देखेंगे कि नया लेनदेन योजना का पालन करता है या नहीं। कोई दूसरा प्राप्तकर्ता या तय रकम से अलग रकम जाँच में पास नहीं होगी। Jeremy Rubin ने यह प्रस्ताव BIP119 में बताया है, जिसे BIP नंबर 2020 में मिला था। [1] [3]

टेम्पलेट ट्रांसफर की बनावट तय करता है: इनपुट कितने पुराने आउटपुट का संदर्भ देंगे और कौन से नए आउटपुट बनेंगे। नए आउटपुट के लिए रकम और स्क्रिप्ट, यानी आगे खर्च करने की शर्तें, तय रहती हैं। अधिक विस्तार से देखें तो BIP119 में लेनदेन का संस्करण; पूरे लेनदेन की समय-संबंधी पाबंदी वाला फ़ील्ड nLockTime; इनपुट के nSequence फ़ील्ड, जो समय-आधारित लॉक पर असर डाल सकते हैं; और जाँचे जा रहे इनपुट का क्रमांक भी शामिल हैं। यदि कोई scriptSig, यानी खर्च के डेटा देने वाली इनपुट स्क्रिप्ट, खाली नहीं है, तो सभी scriptSig फ़ील्ड को समेटने वाला हैश भी जोड़ा जाता है। इसलिए यह केवल प्राप्तकर्ताओं की सूची नहीं है: इसमें शामिल किसी दूसरे डेटा को बदलने से भी टेम्पलेट बदल जाता है। किन पुराने सिक्कों का संदर्भ दिया गया है और उनकी रकम क्या है, यह अलग सवाल है, जिसे नीचे समझेंगे। [1]

बाइट डेटा की मात्रा मापने की एक सामान्य इकाई है। प्रस्तावित जाँच SHA256 से निकाला गया 32 बाइट का टेम्पलेट हैश इस्तेमाल करती है। नोड आउटपुट खर्च करने वाले लेनदेन से वही फिंगरप्रिंट निकालता है और मेल न खाने पर उसे अस्वीकार करता है। डिजिटल हस्ताक्षर निजी कुंजी, यानी एक गुप्त संख्यात्मक मान, से भुगतान की अनुमति का प्रमाण बनाता है, लेकिन उस कुंजी को उजागर नहीं करता। स्क्रिप्ट का दूसरा हिस्सा हस्ताक्षर माँग सकता है; CTV हर स्थिति में उसकी जगह नहीं लेता। दूसरी लंबाई के आर्ग्युमेंट यह जाँच नहीं करते और भविष्य के विस्तार के लिए आरक्षित हैं, हालाँकि रिले नीति उन्हें अस्वीकार कर सकती है। इसलिए गलत आर्ग्युमेंट का अर्थ अपने-आप सुरक्षित लॉक नहीं है। [1] [4] [12]

अगले उदाहरण में हम sats, यानी बिटकॉइन की सबसे छोटी इकाइयों का उपयोग करते हैं। टेम्पलेट हैश में सीधे outpoint, यानी खर्च किए जा रहे खास UTXO का संदर्भ, या उसकी इनपुट रकम शामिल नहीं होती। फिर भी इनपुट की संख्या तय होती है। मान लें केवल एक इनपुट अनुमत है और आउटपुट का कुल योग 99,000 sats है। 100,000 sats का इनपुट 1,000 sats शुल्क छोड़ेगा। आउटपुट के कुल योग से छोटा इनपुट लेनदेन को पूरा नहीं कर सकता। बड़ा इनपुट, यदि आउटपुट वही रहें, तो शुल्क बढ़ाएगा; बची रकम अपने-आप वापस नहीं आएगी। [6] [9]

टेम्पलेट रकम को ऐसे अगले आउटपुट में भेजना अनिवार्य कर सकता है जिसकी स्क्रिप्ट में विलंब और रिकवरी का रास्ता हो। इससे अनचाही निकासी पर प्रतिक्रिया देने का समय रखने वाला वॉल्ट बनाया जा सकता है। लेकिन CTV पूरी सुरक्षा व्यवस्था नहीं है: कुंजियाँ, अगले आउटपुट की शर्तें, निगरानी और रिकवरी का समय पर कन्फर्म होना जरूरी है। कुछ पाबंदियाँ पहले से हस्ताक्षरित लेनदेन से भी बनाई जा सकती हैं, लेकिन उनके लिए सहयोग और कुंजियाँ मिटाने की शर्तें अलग हैं। [8] [5]

ब्लॉक लेनदेन का एक समूह है, जो साझा इतिहास में जोड़ा जाता है। प्रस्तावित भीड़-नियंत्रण में पहले ऐसा आउटपुट कन्फर्म होता है जो रकम को बाद के वितरण से बाँधता है। प्राप्तकर्ताओं के अलग-अलग आउटपुट आगे के लेनदेन में बन सकते हैं, जैसे नेटवर्क कम व्यस्त होने पर। प्राप्तकर्ताओं को योजना की जानकारी और अपना अधिकार लागू करने का तरीका चाहिए। यह उनके पते पर पहले ही कन्फर्म हो चुके सामान्य भुगतान जैसा नहीं है और सीमित ब्लॉक की जगह को असीमित नहीं बनाता। [7] [11]

वॉलेट बिटकॉइन पाने और भेजने वाला ऐप या उपकरण है। आना भुगतान प्रकाशित करने से काफी पहले योजना तैयार कर सकती है, जब भविष्य का शुल्क पता नहीं होता। आउटपुट तय होने पर वह अपने वॉलेट में लौटने वाली रकम मनचाहे ढंग से घटाकर अंतर माइनर को नहीं दे सकती। इसलिए डिज़ाइन में शुल्क बढ़ाने का रास्ता चाहिए। एक विकल्प सही तरह तैयार किया गया CPFP है: अगला लेनदेन मूल लेनदेन का आउटपुट खर्च करता है और ऐसा शुल्क देता है जो माइनर को दोनों शामिल करने के लिए प्रोत्साहित करे। दूसरा विकल्प ऐसा टेम्पलेट है जिसमें शुरू से अतिरिक्त इनपुट की जगह तय हो। केवल एक इनपुट की अनुमति वाले टेम्पलेट में उसे बाद में बस जोड़ नहीं सकते। Mempool किसी खास नोड के अपुष्ट लेनदेन का संग्रह है; उसमें स्वीकार होने से ब्लॉक में शामिल होना तय नहीं हो जाता। [2] [6] [10]

CTV अकेले किसी खास टेम्पलेट की जाँच करता है; यह लेनदेन के सभी डेटा को पढ़ने और मनचाही तुलना करने की सामान्य भाषा नहीं है। इससे आगे के लेनदेन की शाखाओं वाली योजनाएँ बनाई जा सकती हैं, लेकिन इसे सामान्य रिकर्सिव Covenants नहीं समझना चाहिए। दूसरे प्रस्तावित निर्देशों के साथ मिलकर यह अधिक काम कर सकता है। इसलिए देखना जरूरी है कि उदाहरण केवल CTV पर चलता है या कई बदलावों के पूरे समूह पर। [1] [2]

17 अक्टूबर 2026 की जाँच में BIP119 की स्थिति Draft है, यानी यह अभी विकासाधीन प्रस्ताव है। इसमें OP_NOP4 को नई जाँच का काम मिलेगा; यह निर्देश अभी ब्लॉक सत्यापन के दौरान कोई प्रभाव नहीं डालता। साझा नियमों को इस तरह कड़ा करने को Soft Fork कहते हैं। लेकिन दस्तावेज अपने-आप सक्रियण तय नहीं करता। BIP प्रकाशित होने से opcode वास्तव में लागू निर्देश नहीं बन जाता; कोड, किसी डेवलपर का समर्थन या प्रदर्शन वाला वॉलेट भी Bitcoin के मुख्य नेटवर्क, mainnet, पर लागू होने का प्रमाण नहीं है। इसलिए हर प्रदर्शन में उपयोग किए गए नेटवर्क, नियम और उन दूसरे प्रस्तावों को जानना जरूरी है जिन पर वह निर्भर है। [1]

जब तक नियम लागू न हो, केवल स्क्रिप्ट में लिखे होने से उसकी सुरक्षा पर भरोसा नहीं किया जा सकता; कंसेंसस और mempool द्वारा अस्वीकार किया जाना अलग हैं। CTV समर्थित वातावरण में भी, बिना दूसरे रास्ते वाला एक अनिवार्य टेम्पलेट कम रकम के आउटपुट को फँसा सकता है। लेकिन नया छोटा जमा अन्य सही रकम वाले UTXO को अपने-आप नहीं रोकता। सुरक्षित डिजाइन में रकम, शुल्क, बैकअप और रिकवरी के सभी रास्तों की जाँच चाहिए। [1] [4] [6]