OP_RETURN

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

Bitcoin Core उसके सामान्य रूप को NULL_DATA श्रेणी में रखता है। नाम का अर्थ यह नहीं कि अंदर डेटा नहीं है। Solver फ़ंक्शन शुरुआत में OP_RETURN और उसके बाद IsPushOnly जाँच में पास होने वाली स्क्रिप्ट माँगता है, यानी केवल डेटा डालने वाले निर्देश। इसमें पाठ, hash यानी गणना से बनी छोटी डिजिटल छाप, या दूसरे प्रोटोकॉल का रिकॉर्ड हो सकता है। यह वर्गीकरण संदेश का अर्थ प्रमाणित नहीं करता और न ही अपने आप नोड की प्रतीक्षा सूची में प्रवेश सुनिश्चित करता है। रिकॉर्ड से फ़ाइल का मालिकाना हक, लेखक होने का दावा या कानूनी प्रभाव भी अपने आप स्थापित नहीं होता; इनके लिए अलग नियम और प्रमाण चाहिए। [3]

नोड UTXO समूह रखते हैं: ऐसे आउटपुट जो अभी खर्च नहीं हुए और आगे इस्तेमाल हो सकते हैं। OP_RETURN से शुरू होने वाले आउटपुट के बारे में वे पहले से जानते हैं कि कोई उसे खर्च नहीं कर सकता। IsUnspendable उसे पहचानता है और AddCoin उसे UTXO कैश में नहीं जोड़ता। इससे मौजूदा कामकाजी स्थिति का हिसाब घटता है, पूरे इतिहास की जगह नहीं बचती: पुष्टि हो चुका लेनदेन ब्लॉक में रहता है और उसका डेटा भेजना तथा ऐतिहासिक प्रतियों में रखना पड़ता है। UTXO से बाहर रखने का अर्थ डेटा मिटाना नहीं है। यदि कोई इस आउटपुट को रकम देता है, तो वह माइनर का इनाम नहीं बनती। रकम खर्च नहीं हो सकती और बाद का हस्ताक्षर उसे वापस नहीं लाता। [2] [6] [1]

सहमति के नियम तय करते हैं कि नोड किन ब्लॉकों को वैध मानेगा। स्थानीय नीति चुनती है कि mempool, यानी अपुष्ट लेनदेन की प्रतीक्षा सूची, में क्या आएगा और क्या आगे भेजा या माइनिंग के लिए प्रस्तुत किया जाएगा। इससे नोड अपने संसाधन बचाता है। संचालक अलग सेटिंग रख सकते हैं: किसी लेनदेन को आगे भेजने से मना करना यह नहीं बताता कि उसे रखने वाला ब्लॉक सहमति के नियम तोड़ता है। Mempool में स्वीकृति भी पुष्टि का वादा नहीं है। datacarriersize स्थानीय डेटा सीमा तय करता है; यह अपने आप ब्लॉक की वैधता के नियम नहीं बदलता और न पहले से पुष्ट सामग्री मिटाता है। [8]

अक्सर बताई जाने वाली पुरानी डिफ़ॉल्ट व्यवस्था में 1 डेटा आउटपुट और अधिकतम 83 बाइट की स्क्रिप्ट थी, जिसमें आम तौर पर 80 बाइट सामग्री और बाकी निर्देश होते थे। Bitcoin Core 30.0 ने डिफ़ॉल्ट datacarriersize को 100000 किया और कई डेटा आउटपुट की अनुमति दी। कोड हर ऐसे आउटपुट के पूरे scriptPubKey की लंबाई साझा सीमा से घटाता है। वह केवल संदेश की सामग्री नहीं गिनता और स्क्रिप्ट की लंबाई लिखने वाला बाहरी फ़ील्ड भी इसमें शामिल नहीं है। लेनदेन की अन्य सीमाएँ बनी रहती हैं। इसलिए 83 सेट करने से आकार की सीमा वापस आती है, केवल एक आउटपुट वाला पुराना नियम नहीं। ये आँकड़े एक खास संस्करण में हुए बदलाव के हैं, पूरे नेटवर्क का स्थायी नियम नहीं। [7] [4] [8]

याना पूरा दस्तावेज़ रखने के बजाय उसका hash, OP_RETURN में डाल सकती है। जब वह बाद में मूल फ़ाइल दिखाए, तो उसी विधि से छाप फिर निकालकर रिकॉर्ड से मिलाई जा सकती है। मगर उसे फ़ाइल के ठीक वही बाइट और गणना की विधि बचानी होगी; केवल छाप दस्तावेज़ की जगह नहीं ले सकती। मेल होने से सामग्री सच, याना उसकी लेखिका, या फ़ाइल के बनने का सटीक समय सिद्ध नहीं होता। सार्वजनिक रिकॉर्ड पहचानों को जोड़ भी सकता है और hash किया गया डेटा अपने आप निजी नहीं हो जाता। लागत पूरे लेनदेन और ब्लॉक में जगह की माँग पर निर्भर है, केवल संदेश की लंबाई पर नहीं। [1] [8]

सामान्य ऐप संदेशों का एक महत्वपूर्ण और स्पष्ट रूप से तय अपवाद है। BIP 141, ब्लॉक के शुरुआती लेनदेन coinbase में OP_RETURN का उपयोग witness commitment के लिए करता है। यह लेनदेन जाँचने में आवश्यक सहायक डेटा से क्रिप्टोग्राफ़िक संबंध है। संबंधित scriptPubKey कम से कम 38 बाइट का होता है और 0x6a24aa21a9ed से शुरू होता है। कई आउटपुट मेल खाते हों, तो सबसे बड़ा इंडेक्स चुना जाता है, यानी क्रम में आखिरी मेल खाने वाला आउटपुट। ब्लॉक में witness डेटा न हो, तो witness commitment वैकल्पिक है। यहाँ नेटवर्क एक तय संरचना जाँचता है; इसका अर्थ OP_RETURN के बाद लिखे किसी भी पाठ की सच्चाई जाँचना नहीं है। [9]

पहले देखें कि सीमा किस क्लाइंट, संस्करण और सेटिंग की है। फिर असली लेनदेन को डिकोड करके scriptPubKey और बाइट में लिखते समय उसके आसपास आने वाले फ़ील्ड अलग समझें। mempool_datacarrier.py परीक्षण कार्यान्वयन की सीमा वाले मामले दिखाता है; यह लेख उस परीक्षण को स्वयं नहीं चलाता। BIP 110 ने सहमति स्तर पर अतिरिक्त पाबंदियाँ सुझाई थीं, लेकिन वह बंद हो चुका प्रस्ताव है, datacarriersize से चालू होने वाला नियम नहीं। पुराने संस्करण का विवरण भी हर नोड या भविष्य के संस्करण के समान व्यवहार का वादा नहीं है। किसी खास सेटिंग और लेनदेन की वास्तविक पुष्टि में अंतर है। [10] [8] [11]