Miniscript

एना रोज़मर्रा में अपनी कुंजी से कॉइन खर्च करना चाहती है। डिजिटल हस्ताक्षर निजी कुंजी, यानी एक गुप्त संख्यात्मक मान, से भुगतान की अनुमति का प्रमाण बनाता है, लेकिन उस कुंजी को उजागर नहीं करता। वॉलेट बिटकॉइन पाने और भेजने वाला ऐप या उपकरण है। साथ ही एना पीटर के लिए एक रास्ता रखना चाहती है: उस आउटपुट की पुष्टि के बाद 144 ब्लॉक बीतने पर पीटर अपनी कुंजी से उन्हें खर्च कर सके। इस मंशा को spending policy, यानी खर्च करने के नियम कहते हैं। Miniscript इसे ऐसा सटीक रूप देने में मदद करता है जिसे वॉलेट समझ सके। पीटर को फिर भी अपनी कुंजी चाहिए; इंतज़ार उसकी जगह नहीं लेता। यह वैकल्पिक पहुँच के रास्तों का सरल उदाहरण है, अपने-आप होने वाला ट्रांसफ़र या एना की कुंजी खोने का पता लगाने वाला उपाय नहीं। [1] [2] [10]

शब्दों में लिखे नियम अभी वह प्रोग्राम नहीं हैं जिसे नेटवर्क जाँचता है। कंपाइलर उनके लिए एक खास Miniscript चुनकर उसे Bitcoin Script में बदल सकता है। Output Descriptor तैयार हुए स्क्रिप्ट के साथ कुंजियाँ और ज़रूरत होने पर उनके derivation paths, यानी कुंजियाँ निकालने के रास्ते बताता है। इसमें नकल की गलती पकड़ने वाला checksum भी हो सकता है। खर्च करते समय नेटवर्क असली स्क्रिप्ट और दिए गए डेटा जाँचता है, शुरुआती वाक्य नहीं। Miniscript कोई नया निर्देश नहीं जोड़ता और वैधता के साझा नियम, यानी consensus नहीं बदलता। इससे हर संभव Bitcoin Script नहीं लिखा जा सकता। [1] [3] [6]

ब्लॉक लेनदेन का एक समूह है, जो साझा इतिहास में जोड़ा जाता है। पीटर के उदाहरण में 144 ब्लॉक आउटपुट की पुष्टि से गिने जाते हैं। आउटपुट एक तय रकम है जिसके साथ खर्च करने की शर्तें जुड़ी हैं। इसका अर्थ ठीक एक दिन या वॉलेट बनाने के बाद बीता समय नहीं है। Miniscript सापेक्ष इंतज़ार को older(n) लिखता है। इसमें CSV और खर्च करने वाले इनपुट के nSequence फ़ील्ड का उपयोग होता है; उम्र की जाँच में nSequence का अर्थ BIP 68 तय करता है। इसके उलट after(n), CLTV और निरपेक्ष nLockTime से तय ब्लॉक ऊँचाई या समय-सीमा बताता है। वॉलेट को ट्रांज़ैक्शन के फ़ील्ड सही रखने और बाकी शर्तें पूरी करने की ज़रूरत है। ऊँचाई और समय वाले लॉक असंगत ढंग से नहीं जोड़े जा सकते; इंतज़ार पूरा होना अपने-आप कुछ नहीं भेजता। [1] [7] [8] [9] [11]

नियमों का वर्णन दिखाना काफ़ी नहीं है। वॉलेट को ऐसी जानकारी देनी होती है जो किसी अनुमत रास्ते की शर्तें पूरी करे: जैसे हस्ताक्षर या ऐसा गुप्त मान जिसका hash माँगे गए hash से मिले। उस मान को preimage कहते हैं। hash डेटा की डिजिटल छाप है; यहाँ जाँचा जाता है कि दिए गए गुप्त मान से वही छाप बनती है या नहीं जो माँगी गई है। शर्त पूरी करने को satisfaction कहते हैं और ज़रूरी इनपुट डेटा ट्रांज़ैक्शन के witness का हिस्सा होते हैं। शाखाएँ जोड़ते समय कभी एक छोटी शर्त को तय तरीके से असत्य बनाना पड़ता है ताकि दूसरा रास्ता चुना जा सके। यह dissatisfaction है, पूरे भुगतान का अमान्य होना नहीं। सॉफ़्टवेयर सही रास्ता तैयार कर सकता है, पर गायब निजी कुंजी या अनजान गुप्त जानकारी बना नहीं सकता। [1] [12]

PSBT तैयार ट्रांज़ैक्शन और अतिरिक्त जानकारी को वॉलेट तथा हस्ताक्षर करने वाले उपकरणों के बीच भेजने का फ़ॉर्मैट है। केवल PSBT समर्थन काफ़ी नहीं है: प्रोग्राम और Hardware Wallet को descriptor तथा उसकी शर्तें समझनी चाहिए। Bitcoin Core ने संस्करण 24 में P2WSH के Miniscript को केवल देखने की सुविधा, संस्करण 25 में हस्ताक्षर और संस्करण 26 में Taproot descriptors में उपयोग जोड़ा। इसलिए कॉइन देख पाना और उन्हें खर्च कर पाना अलग क्षमताएँ हैं। सेटअप करते समय उपकरण की वास्तविक क्षमता के अनुसार भरोसेमंद स्क्रीन पर कुंजियाँ, आवश्यक हस्ताक्षर, इंतज़ार और सभी वैकल्पिक रास्ते जाँचें। [3] [4] [5]

Seed Phrase कुंजियाँ वापस लाती है, लेकिन अपनी जटिल शर्तों में यह हमेशा नहीं बताती कि उन्हें दूसरी कुंजियों और स्क्रिप्ट से कैसे जोड़ा गया था। यह बैकअप शब्दों के एक क्रम के रूप में लिखा होता है, जिससे वॉलेट अपनी कुंजियाँ निकाल सकता है। checksum सहित सटीक descriptor, कुंजियों का मिलान, derivation paths और प्राप्ति तथा बची रकम लौटाने वाले पतों का अंतर सुरक्षित रखें। नेटवर्क, पतों की सीमा और पुराने रिकॉर्ड खोजना कहाँ से शुरू करना है, अलग से दर्ज करें। सार्वजनिक descriptor निजी कुंजी नहीं है, मगर भुगतान का इतिहास उजागर कर सकता है। इस्तेमाल से पहले Regtest या Signet के परीक्षण वातावरण में केवल देखने वाले वॉलेट की बहाली और हर तय खर्च-पथ को आज़माएँ। [5] [6]

pk(), older(), after() और sha256() हस्ताक्षर, इंतज़ार या गुप्त जानकारी की माँग बताते हैं। and_v(), or_d() और thresh() शर्तों को जोड़ते हैं। v: जैसे wrappers, छोटे व्यंजक का अर्थ बनाए रखते हुए मूल्यांकन का तरीका बदलते हैं। B, V, K और W प्रकार तय करते हैं कि हिस्से stack पर डेटा कैसे आगे देते हैं। stack स्क्रिप्ट का काम करने का स्थान है; हर दो हिस्से एक-दूसरे से नहीं जुड़ सकते। प्रकारों की जाँच असंगत जोड़ पकड़ सकती है। लेकिन यह तय नहीं करती कि एना किस पर भरोसा करे या उसने समझदारी वाला वैकल्पिक रास्ता चुना है या नहीं। [1] [2]

यह संरचना खर्च से पहले स्क्रिप्ट और witness का आकार, operations, हस्ताक्षर जाँचों और stack के तत्वों की संख्या समझने देती है। इससे अलग रास्तों की लागत का अनुमान और तय सीमाओं के उल्लंघन का पता चलता है। वातावरण मायने रखता है: P2WSH शर्तों को SegWit में रखता है, जबकि Tapscript, Taproot में इस्तेमाल होने वाले स्क्रिप्ट को कहते हैं। दोनों की सीमाएँ पूरी तरह समान नहीं हैं। consensus के साथ सामान्य ट्रांज़ैक्शन relay नियम भी लागू होते हैं। इसलिए विश्लेषण यह प्रमाणपत्र नहीं है कि हर वॉलेट तय प्रक्रिया चला सकता है। [1]

सार्वजनिक कुंजी से हस्ताक्षर की जाँच की जाती है; उसे गुप्त रखना ज़रूरी नहीं है। malleability का विश्लेषण देखता है कि क्या कोई बाहरी व्यक्ति एक वैध satisfaction को दूसरी वैध satisfaction में बदल सकता है। इसकी गारंटी खास मान्यताओं पर निर्भर है: हमलावर के पास प्रतिभागियों की निजी कुंजियाँ नहीं हैं, वह ईमानदार उपयोगकर्ता से अधिक preimages नहीं जानता और केवल एक satisfaction देखता है। सार्वजनिक कुंजियाँ दोहराई न जाना और सामान्य स्वीकार-नियम भी मान्यताएँ हैं; माइनर के पास साधारण relay नोड से अलग विकल्प हो सकते हैं। यह हर दुर्भावनापूर्ण प्रतिभागी, खोए बैकअप या गलत custody योजना से सुरक्षा नहीं है। उन सवालों की अलग जाँच चाहिए। [1]

कंपाइलर समान नियमों को अलग तरीकों से लिख सकता है, जिनमें स्क्रिप्ट और witness के आकार अलग हों। वह लागत के मॉडल के अनुसार चुनता है। policy लिखने की भाषा में शाखा पर 9@ जैसा चिह्न उसके इस्तेमाल की सापेक्ष संभावना का संकेत है, हस्ताक्षरों की संख्या या नेटवर्क की अनुमति नहीं। अलग compilation से अलग स्क्रिप्ट और इसलिए अलग पते बन सकते हैं। बहाली के समय नियम फिर अपने शब्दों में लिखकर compile कर देना काफ़ी नहीं है। सहेजा हुआ सटीक रूप, उससे बने पतों की जाँच और आज़माया हुआ हस्ताक्षर-पथ ज़रूरी हैं। [2] [5]