Covenants

आना अपनी बचत Bitcoin में रखती है। वॉलेट बिटकॉइन पाने और भेजने वाला ऐप या उपकरण है। उसके वॉलेट में दिखने वाला बैलेंस पिछली ट्रांजैक्शनों के उन आउटपुट से बनता है जो अभी खर्च नहीं हुए हैं; इन्हें UTXO कहते हैं। हर आउटपुट में रकम और उसे खर्च करने की शर्तें होती हैं। ये शर्तें Bitcoin Script नाम के छोटे प्रोग्राम में लिखी होती हैं। डिजिटल हस्ताक्षर निजी कुंजी, यानी एक गुप्त संख्यात्मक मान, से भुगतान की अनुमति का प्रमाण बनाता है, लेकिन उस कुंजी को उजागर नहीं करता। Multisig कई हस्ताक्षर माँग सकता है और Timelock प्रतीक्षा की शर्त जोड़ता है। Covenant अगली ट्रांजैक्शन की बनावट भी सीमित कर सकता है, जैसे धन किन आउटपुट में जाना चाहिए। सही कुंजी रखने वाले चोर को भी वह नियम मानना होगा। लेकिन खर्च के सभी उपलब्ध रास्ते देखना जरूरी है: यदि कोई दूसरी शाखा पाबंदी से बचने देती है, तो उस पाबंदी पर भरोसा नहीं किया जा सकता। [1] [5] [9] [11]

मान लें कि आना बचत ऐसे वॉल्ट में रखती है जिसमें निकासी के लिए इंतजार करना पड़ता है। यहाँ वॉल्ट कोई खास उपकरण नहीं, बल्कि खर्च करने के नियमों की व्यवस्था है। उसकी रोजमर्रा की कुंजी निकासी शुरू कर सकती है, लेकिन धन पहले प्रतीक्षा वाले आउटपुट में जाएगा। तय अवधि बीतने के बाद ही उसे इच्छित प्राप्तकर्ता को भेजा जा सकेगा। यदि चोर निकासी शुरू करे, तो आना इंतजार के दौरान पहले से तैयार बचाव के रास्ते से धन को अधिक सुरक्षित शर्तों के अधीन भेज सकती है। मगर उसे निकासी का पता लगना चाहिए और बचाव ट्रांजैक्शन की समय रहते ब्लॉक में पुष्टि होनी चाहिए। ब्लॉक लेनदेन का एक समूह है, जो साझा इतिहास में जोड़ा जाता है। इससे पूरा हो चुका भुगतान वापस नहीं होता, न ही बिना हस्तक्षेप के धन अपने-आप बच जाता है। कौन-कौन से विकल्प उपलब्ध हैं, यह वॉल्ट के डिज़ाइन पर निर्भर है। [6] [10]

ऐप का निकासी देर से करने का वादा केवल उसके संचालक का वादा हो सकता है। इसके विपरीत, Bitcoin की स्क्रिप्ट में लिखा नियम नोड जाँचते हैं। नोड ऐसे प्रोग्राम हैं जो नेटवर्क के साझा नियमों के अनुसार ट्रांजैक्शनों को सत्यापित करते हैं। उपयुक्त covenant संरचना में उन्हें पाबंदी तोड़ने वाला ट्रांसफर अस्वीकार करना होता है। एक प्रस्तावित साधन OP_CHECKTEMPLATEVERIFY, यानी CTV है, जिसे BIP119 में बताया गया है। BIP, Bitcoin के लिए प्रस्ताव रखने वाला दस्तावेज होता है। CTV जाँची जा रही ट्रांजैक्शन के चुने हुए डेटा के हैश की तुलना पहले से रखी छाप से करेगा। यहाँ हैश को डेटा की छोटी, जाँची जा सकने वाली छाप समझें। तय प्राप्तकर्ता या रकम बदलने पर छाप भी बदल जाएगी, इसलिए टेम्पलेट से अलग ट्रांसफर जाँच में पास नहीं होगा। ऐप में केवल “वॉल्ट” नाम लिख देने से यह सुरक्षा नहीं मिलती। [2]

CTV ट्रांजैक्शन को पहले से तैयार टेम्पलेट से बाँधता है, जिसमें उसके आउटपुट भी शामिल हैं। दूसरे तरीकों पर भी शोध चल रहा है। BIP443 का OP_CHECKCONTRACTVERIFY ऐसे आउटपुट का प्रस्ताव है जो खास डेटा से जुड़ा सत्यापनीय कमिटमेंट रखते हैं। यहाँ कमिटमेंट का अर्थ है कि बाद में एक मान की जगह दूसरा रखने पर जाँच में फर्क पकड़ में आ जाएगा। डेटा किसी कॉन्ट्रैक्ट की स्थिति बता सकता है, जैसे साझा धन का मौजूदा बँटवारा। अगला आउटपुट नई स्थिति रख सकता है, बशर्ते तय नियम पूरे हों। इसलिए CTV और यह प्रस्ताव एक ही चीज के दो नाम नहीं हैं। हर डिज़ाइन में देखें कि क्या पहले तय करना होगा, क्या बाद में बदल सकता है और पूरी संरचना को किन अतिरिक्त साधनों की जरूरत है। [2] [7]

रिकर्सिव संरचना यह माँग कर सकती है कि अगला आउटपुट भी कोई खास पाबंदी रखे। इस तरह नियम कई ट्रांजैक्शनों में जारी रह सकता है, जैसे किसी कॉन्ट्रैक्ट का स्टेट चरण-दर-चरण बदलते समय। इसका अर्थ एक स्क्रिप्ट जाँचते समय अनंत लूप चलाना नहीं है। Russell O’Connor और Marta Piekarska ने 2017 के शोधपत्र में ऐसी संरचनाएँ समझाई थीं; दोहराव की क्षमता खास प्रस्ताव पर निर्भर है। [3]

पहले से हस्ताक्षरित ट्रांजैक्शन, समय-आधारित लॉक और कुंजी प्रबंधन से कुछ पाबंदियाँ तैयार की जा सकती हैं। पर इसमें कुंजी का भरोसेमंद ढंग से मिटना, सारे ट्रांजैक्शन सहेजना या आगे भी सहयोग मिलना जरूरी हो सकता है। ऐसा Multisig जिसमें दूसरा हस्ताक्षरकर्ता अनुचित भुगतान रोकता है, अलग भरोसे की धारणा लाता है। इस्तेमाल का अनुभव समान हो तो भी नियम लागू होने और बहाली के तरीके समान नहीं होते। [5] [6]

वॉल्ट के अलावा साझा UTXO और समय के साथ अलग-अलग चरणों में निपटने वाले भुगतान की तैयारी पर शोध होता है। उद्देश्य लगातार सहयोग की जरूरत घटाना या ब्लॉक की जगह बेहतर उपयोग करना हो सकता है। इससे असीमित ट्रांजैक्शन या हमेशा कम शुल्क की गारंटी नहीं मिलती। डिज़ाइन को अकेले प्रतिभागी के बाहर निकलने, दूसरों के उपलब्ध न होने और भीड़ के समय शुल्क देने का तरीका भी समझाना होगा। [2] [7]

17 अक्टूबर 2026 को BIP119 और BIP443 की स्थिति Draft है, यानी वे अभी विकासाधीन प्रस्ताव हैं। पुराने BIP345, OP_VAULT, की स्थिति Closed है और उसमें BIP443 को प्रस्तावित विकल्प बताया गया है। उस दस्तावेज के बंद होने का अर्थ वॉल्ट पर शोध का अंत नहीं है। इसी तरह BIP नंबर मिलना यह नहीं बताता कि नेटवर्क ने बदलाव अपना लिया है। परीक्षण नेटवर्क या प्रदर्शन वाला वॉलेट कोई फीचर दिखा सकता है, जबकि Bitcoin के मुख्य नेटवर्क, mainnet, के नियम अभी बदले ही न हों। यदि कोई सेवा covenant वाला वॉल्ट पेश करती है, तो जाँचें कि वह वास्तव में किस नेटवर्क और किन नियमों पर काम करती है। [6] [8]

बहुत सीमित टेम्पलेट या रकम, स्क्रिप्ट अथवा शुल्क व्यवस्था की गलती इच्छित खर्च को असंभव बना सकती है। नए ऑपरेशन सुरक्षित सत्यापन के दायरे को भी बढ़ाते हैं। इसलिए सहमति के बदलावों को सटीक विनिर्देश और गलती के समय के व्यवहार से परखना चाहिए। Covenant अपने-आप किसी दूसरे व्यक्ति को आपके मौजूदा UTXO की शर्तें बाद में बदलने का अधिकार नहीं देता। [4] [8]

किसी खास समाधान के लिए पूछें कि निकासी या बचाव कौन शुरू कर सकता है, प्रतिक्रिया के लिए कितना समय मिलता है और क्या किसी को लगातार चेन देखनी होगी। बैकअप, शुल्क, बाहर निकलने के रास्ते और वह वास्तव में किस नेटवर्क पर चलता है, यह भी जाँचें। Covenants अपने धन पर आपका नियंत्रण बढ़ा सकते हैं, लेकिन उत्पाद के विवरण में यह शब्द होना उस नियंत्रण का प्रमाण नहीं है। [3] [6]