Bitcoin Script

Alice को 20 000 sat, यानी बीस हज़ार satoshi मिलते हैं। satoshi बिटकॉइन की सबसे छोटी इकाई है। नेटवर्क उसके नाम का खाता नहीं खोलता। वह लेनदेन का एक आउटपुट बनाता है: रकम और उसे बाद में खर्च करने की शर्त। जब तक आउटपुट खर्च नहीं हुआ है, उसे UTXO कहते हैं। आम भुगतान में शर्त संबंधित कुंजी से किया गया हस्ताक्षर माँगती है। जब Alice बाद में भुगतान करती है, तो उसका वॉलेट यह आउटपुट चुनता है, नए लेनदेन के इनपुट में उसका संदर्भ देता है और डिजिटल हस्ताक्षर बनाता है। इसके लिए वह निजी कुंजी इस्तेमाल करता है, लेकिन उसे कहीं भेजता नहीं। दूसरे लोग सार्वजनिक कुंजी से हस्ताक्षर जाँचते हैं। केवल Alice का भुगतान प्राप्त करने वाला पता जानना पर्याप्त नहीं है। मूल आउटपुट की शर्तें scriptPubKey फ़ील्ड में लिखी होती हैं और Bitcoin Script तय करता है कि उनका पूरा होना कैसे जाँचा जाए। नोड Alice को पहचानने वाला कर्मचारी नहीं, बल्कि नियम जाँचने वाला कंप्यूटर है। हस्ताक्षर के अलावा उसे यह भी जाँचना होता है कि वही आउटपुट पहले ही खर्च तो नहीं हो चुका। सभी लागू नियम पूरे होने पर ही लेनदेन मान्य होता है। [4] [2]

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

आगे के अध्याय बताते हैं कि लेनदेन के भीतर शर्तें कैसे लिखी जाती हैं। रोज़मर्रा के भुगतान के लिए यह जानना ज़रूरी नहीं है। scriptSig फ़ील्ड और witness नाम का हिस्सा सत्यापन का डेटा देते हैं। हैश डेटा की पहचान बताने वाली छाप है और समय-लॉक किसी तय सीमा से पहले खर्च रोकता है। स्टैक को डेटा की ऐसी ढेरी समझें जिसमें ऊपर से चीज़ें रखी और निकाली जाती हैं। Script स्टैक की मदद से डेटा संसाधित करता है। मान स्टैक पर रखे जाते हैं और ऑपकोड कहलाने वाले निर्देश उन्हें निकालते हैं, तुलना करते हैं या दूसरे ढंग से संसाधित करते हैं। हस्ताक्षर संबंधी निर्देश हस्ताक्षरों की जाँच करते हैं; इस सत्यापन में निजी कुंजियों का उपयोग या हस्ताक्षर बनाना शामिल नहीं है। यह भाषा हस्ताक्षर, हैश की शर्तों और समय-लॉक को जोड़ सकती है। इसमें सामान्य लूप नहीं हैं और यह ट्यूरिंग-पूर्ण नहीं है। यानी सामान्य उपयोग की प्रोग्रामिंग भाषा में लिखी जा सकने वाली हर गणना इसमें नहीं लिखी जा सकती। नोड को संबंधित आउटपुट प्रकार और स्क्रिप्ट संस्करण के लिए तय सटीक नियमों का पालन करना होता है। [1] [3]

P2PKH (Pay to Public Key Hash) में आउटपुट का सामान्य रूप OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG होता है। इनपुट अपने scriptSig में हस्ताक्षर और सार्वजनिक कुंजी देता है। सत्यापन पहले जाँचता है कि सार्वजनिक कुंजी का हैश आउटपुट में मौजूद मान से मेल खाता है या नहीं, और फिर हस्ताक्षर की जाँच करता है। इसलिए केवल पता या सार्वजनिक कुंजी जानना ऐसे खर्च के लिए पर्याप्त नहीं है। निजी कुंजी हस्ताक्षर करने वाला वॉलेट इस्तेमाल करता है, लेनदेन जाँचने वाला नोड नहीं। [1]

P2SH, BIP16 के अनुसार, आउटपुट में स्क्रिप्ट का हैश रखता है। उसे खर्च करने वाला इनपुट सही redeemScript, यानी खर्च के समय सामने लाई जाने वाली स्क्रिप्ट, और आवश्यक डेटा देता है। उसका scriptSig केवल डेटा स्टैक पर रखने वाले निर्देश रख सकता है। नोड पहले हैश का मेल जाँचता है और फिर स्टैक की बाकी वस्तुओं के साथ redeemScript का मूल्यांकन करता है। केवल हैश सही होने से खर्च नहीं हो सकता; उस स्क्रिप्ट की शर्तें भी पूरी होनी चाहिए। [5]

SegWit संस्करण 0 में सत्यापन का डेटा लेनदेन के witness नाम वाले हिस्से में चला जाता है। यह डेटा की वस्तुओं की सूची है, अपने-आप में स्क्रिप्ट नहीं। P2WPKH हस्ताक्षर और सार्वजनिक कुंजी इस्तेमाल करता है; P2WSH में witnessScript भी होता है, जिसका SHA256 हैश आउटपुट से मेल खाना चाहिए। नेटिव SegWit में scriptSig खाली होता है। P2SH में लपेटे जाने पर इसमें केवल संबंधित witness प्रोग्राम को स्टैक पर रखने वाला निर्देश होता है; वास्तविक सत्यापन डेटा witness में ही रहता है। [6]

हस्ताक्षर का सत्यापन तय प्रक्रिया से लेनदेन से निकाले गए संदेश पर किया जाता है। SIGHASH मोड बताता है कि लेनदेन के किन हिस्सों को हस्ताक्षर बदलाव से बचाता है। इसलिए यह अपने-आप नहीं माना जा सकता कि हर हस्ताक्षर पूरे लेनदेन को शामिल करता है। BIP143, SegWit संस्करण 0 में हस्ताक्षर संबंधी काम के लिए खर्च किए जा रहे आउटपुट की रकम हमेशा शामिल करता है। वॉलेट को सही डेटा और चुने हुए मोड की जानकारी होनी चाहिए। Script जाँचते समय यह नहीं परखता कि हस्ताक्षर करने वाला व्यक्ति क्या करना चाहता था। [7]

Taproot, BIP341 के अनुसार, P2TR (Pay to Taproot) आउटपुट खर्च करने के दो रास्ते देता है। कुंजी वाला रास्ता स्क्रिप्ट दिखाए बिना आउटपुट की सार्वजनिक कुंजी के आधार पर Schnorr हस्ताक्षर जाँचता है। इसके विपरीत, स्क्रिप्ट वाला रास्ता चुनी हुई स्क्रिप्ट और control block कहलाने वाला नियंत्रण ब्लॉक दिखाता है, जो उसका आउटपुट से संबंध साबित करता है। वृक्ष की बाकी स्क्रिप्ट दिखाना ज़रूरी नहीं है। सामने लाई गई स्क्रिप्ट के नियम संबंधित पत्ते के संस्करण पर भी निर्भर करते हैं। [8]

BIP342, Taproot के संस्करण 0xc0 वाले पत्तों के लिए Tapscript परिभाषित करता है। यहाँ हस्ताक्षर निर्देश Schnorr हस्ताक्षर इस्तेमाल करते हैं और OP_CHECKSIGADD से कई हस्ताक्षर माँगने वाली शर्त बनाई जा सकती है। पुराने OP_CHECKMULTISIG को चलाने की अनुमति नहीं है। पहले की 10 000 बाइट वाली स्क्रिप्ट लंबाई सीमा और पुराने नियमों से गिने जाने वाले 201 ऑपकोड की सीमा यहाँ लागू नहीं होतीं। हस्ताक्षर संबंधी क्रियाओं की संख्या witness के आकार से निकाले गए बजट तक सीमित होती है; स्टैक की सीमाएँ अब भी मौजूद हैं। इसलिए किसी एक संस्करण की सीमाओं को पूरे Script का सामान्य गुण नहीं बताना चाहिए। [9]

सहमति के नियम तय करते हैं कि ब्लॉक में कोई खर्च मान्य है या नहीं। लेनदेन की मानकता से मतलब नोड के उन अतिरिक्त स्थानीय नियमों से है जिनके अनुसार वह अपुष्ट लेनदेन Mempool में लेता और आगे भेजता है; यह मानक बनाने की प्रक्रिया नहीं है। इसलिए सहमति के अनुसार मान्य लेनदेन भी आम तौर पर आगे न भेजा जाए, ऐसा हो सकता है। Tapscript में OP_SUCCESSx पर खास ध्यान देना चाहिए: पहले की जाँचें सफल होने के बाद, डिकोडिंग में इसकी पहचान होते ही सामान्य निष्पादन और स्टैक की जाँचों से पहले स्क्रिप्ट का सत्यापन सफल घोषित हो जाता है। यह भविष्य के विस्तार के लिए छोड़ी गई जगह है, खर्च की कोई सामान्य सुरक्षित शर्त नहीं। [10] [9]