Opcode

आना पीटर को भुगतान करना चाहती है। वॉलेट लेनदेन और आवश्यक हस्ताक्षर तैयार करता है। वॉलेट बिटकॉइन पाने और भेजने वाला ऐप या उपकरण है। नोड ऐसा प्रोग्राम है जो लेनदेन और ब्लॉक की जाँच करता है और नेटवर्क के दूसरे सहभागियों से संपर्क रखता है। नोड जाँचते हैं कि आना को चुने हुए सिक्के खर्च करने का अधिकार था या नहीं। इनमें कुछ जाँचों की भाषा Bitcoin Script है। Opcode उसका एक कदम है, जैसे हस्ताक्षर जाँचना। सामान्य भुगतान में आना निर्देश हाथ से नहीं लिखती। लेकिन नोड मालिक के नाम या “हस्ताक्षरित” लिखे होने पर भरोसा नहीं कर सकता; उसे शर्तें जाँचनी होती हैं। सही स्क्रिप्ट पूरे लेनदेन के सत्यापन का केवल एक हिस्सा है। [1] [4]

पढ़ने योग्य रूप में OP_DUP या OP_CHECKSIG दिख सकते हैं। ये इंसानों के लिए निर्देशों के नाम हैं; स्क्रिप्ट में इन्हें एक बाइट के कोड से दर्शाया जाता है। बाइट डेटा की मात्रा मापने की एक सामान्य इकाई है। दूसरे हिस्सों में सार्वजनिक कुंजी जैसा डेटा होता है। सार्वजनिक कुंजी से हस्ताक्षर की जाँच की जाती है; उसे गुप्त रखना ज़रूरी नहीं है। OP_PUSHDATA परिवार के निर्देश बताते हैं कि आगे के कितने बाइट डेटा के रूप में डालने हैं। उस डेटा के अंदर के बाइट दोबारा निर्देश बनकर नहीं चलते। रेसिपी में “नमक डालें” और कटोरे में डाली गई असली सामग्री का अंतर सोचिए। [1] [2]

कागज़ की पर्चियों का ढेर सोचिए, जिसमें ऊपर की पर्ची उठाई जाती है। स्क्रिप्ट का मूल कार्य-स्टैक ऐसे ही चलता है। OP_DUP ऊपर की मद की प्रतिलिपि बनाता है और OP_DROP ऊपर की मद हटाता है। खाली न होने वाले स्टैक पर पहले OP_DUP और फिर OP_DROP चलाएँ, तो सामग्री पहले जैसी हो जाती है। सिक्के दोगुने नहीं हुए, केवल काम का डेटा नकल हुआ। जरूरी मद न होने पर जाँच विफल हो सकती है। क्रम और सटीक एन्कोडिंग भी महत्वपूर्ण हैं। [1]

OP_EQUAL ऊपर की दो मदें लेकर उनके बाइट का मिलान करता है और उनकी जगह परिणाम रखता है। OP_EQUALVERIFY अंतर होने पर तुरंत विफल होता है; समानता होने पर परिणाम स्टैक पर छोड़े बिना आगे बढ़ता है। इनमें से कोई अपने आप हस्ताक्षर नहीं जाँचता। सार्वजनिक कुंजी की दो समान प्रतियाँ कोई भी दे सकता है। यह सिद्ध करने के लिए उचित हस्ताक्षर जाँच चाहिए कि किसी ने आवश्यक संदेश पर हस्ताक्षर करने की क्षमता दिखाई। [1] [4]

OP_CHECKSIG सार्वजनिक कुंजी और लेनदेन से बने संदेश के आधार पर हस्ताक्षर जाँचता है; निजी कुंजी उजागर नहीं होती। निजी कुंजी एक गुप्त संख्यात्मक मान है, जिससे ऐसा हस्ताक्षर बनाया जाता है। sighash सेटिंग तय करती है कि हस्ताक्षर किन हिस्सों को शामिल करता है। हर मोड पूरे लेनदेन पर हस्ताक्षर नहीं करता। पुराने स्क्रिप्ट और SegWit संस्करण 0 एक हस्ताक्षर एल्गोरिदम ECDSA का उपयोग करते हैं। Taproot के स्क्रिप्ट नियम Tapscript सामान्य 32 बाइट की कुंजियों के लिए दूसरा एल्गोरिदम Schnorr लेते हैं। इस संदर्भ के बिना निर्देश का नाम पर्याप्त नहीं। [1] [3]

कोई शर्त सामान्य खर्च या वैकल्पिक पुनर्प्राप्ति का रास्ता दे सकती है। OP_IF और OP_ELSE स्टैक के मान के आधार पर शाखा चुनते हैं; OP_ENDIF सशर्त भाग बंद करता है। Bitcoin Script में मनमाने ढंग से दोहराए जाने वाले सामान्य प्रोग्राम लूप नहीं हैं। लेकिन इसका मतलब यह नहीं कि न चलने वाली शाखा की हर बात अनदेखी कर सकते हैं। कुछ निर्देश स्क्रिप्ट पढ़ते समय ही जाँचे जाते हैं; उनका प्रकार और नियमों का संस्करण मायने रखते हैं। [1] [3]

CLTV, यानी OP_CHECKLOCKTIMEVERIFY, ब्लॉक की चेन में स्थिति बताने वाली ऊँचाई जैसी निरपेक्ष सीमा लागू कर सकता है। CSV, यानी OP_CHECKSEQUENCEVERIFY, लेनदेन की उम्र के नियमों के साथ खर्च किए जाने वाले आउटपुट की पुष्टि से सापेक्ष देरी लागू करता है। आउटपुट पहले मिली रकम और खर्च की शर्तों का रिकॉर्ड है। ये निर्देश लेनदेन के फ़ील्ड जाँचते हैं; टाइमर नहीं चलाते, पैसे नहीं भेजते और हस्ताक्षर का विकल्प नहीं बनते। किसी उपयोग में सही समय-लॉक को दूसरी शर्तों से जोड़ना पड़ता है। [7] [8] [9]

तकनीकी उदाहरण पढ़ने से पहले तय करें कि वह पुराने स्क्रिप्ट, SegWit या Tapscript का है। Tapscript हस्ताक्षर जाँचों को जोड़ने के लिए OP_CHECKSIGADD लाता है। दूसरी ओर OP_CHECKMULTISIG चलने पर विफल होता है; न चलने वाली शाखा में इन नियमों के तहत उसे अनदेखा किया जाता है। नाम विरोधी नहीं, सत्यापन का वातावरण अलग है। Opcodes की सूची ऐसे सार्वभौमिक पुर्जे नहीं जिनका प्रारूप बदलते समय बिना सोचे इस्तेमाल कर सकें। [1] [3] [6]

BIP 342 भविष्य के Tapscript विस्तारों के लिए OP_SUCCESSx परिवार सुरक्षित रखता है। पिछली जाँचें सफल होने के बाद डिकोडिंग में ऐसा निर्देश मिलना ही आगे की स्क्रिप्ट जाँचें छोड़कर सफलता देने के लिए पर्याप्त है, चाहे वह न चलने वाली शाखा में हो। डाले गए डेटा के अंदर संयोग से वही बाइट होने पर ऐसा नहीं होता। यह नियम बदलने की गुंजाइश है, पहले से सक्रिय नई सुरक्षा नहीं। अभी अपरिभाषित भविष्य के अर्थ पर टिकी शर्त लेखक की उम्मीद के अनुसार रकम नहीं बचा सकती। [1] [3]

Full Node वैधता के नियम स्वतंत्र रूप से जाँचता है, लेकिन अपुष्ट लेनदेन स्वीकारने और आगे भेजने के लिए कड़े नियम रख सकता है। उदाहरण के लिए Bitcoin Core v29.0 डिफ़ॉल्ट रूप से उन लेनदेन को आगे भेजने से इनकार करता है जो Tapscript में OP_SUCCESSx निर्देश का उपयोग करते हैं, भले सहमति के नियम उन्हें ब्लॉक में अनुमति दें। उदाहरण पढ़ते समय संस्करण, शुरुआती डेटा, हस्ताक्षर का दायरा और विफलता के कारण देखें। पढ़ने योग्य सिंटैक्स सुरक्षित वॉलेट का प्रमाण नहीं; सामान्य उपयोग में यह काम जाँचे गए सॉफ़्टवेयर को सौंपते हैं। [1] [5]