PSBT v2

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

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

किसी ऐप या उपकरण पर PSBT समर्थन लिखा होना v2 समर्थन का प्रमाण नहीं है। पूरे क्रम की जाँच ज़रूरी है: विशेष कार्यक्रमों और उपकरणों के बीच फ़ाइल बनाना, आयात करना, हस्ताक्षर करना और नतीजा वापस भेजना। PSBT v0 और v2 को सीधे एक-दूसरे की जगह इस्तेमाल नहीं किया जा सकता। v0 में बदलने के लिए अहस्ताक्षरित लेनदेन बनाना और उस संस्करण के नियमों के अनुसार फ़ील्ड समायोजित करना पड़ता है; केवल संख्या बदलना काफ़ी नहीं। Bitcoin आउटपुट खर्च करने की शर्तें तय करने का नया तरीका Taproot भी v2 जैसा नहीं है। BIP 371 दोनों PSBT संस्करणों के लिए उससे संबंधित हस्ताक्षर जानकारी निर्धारित करता है। छोटी राशि से पूरे क्रम का परीक्षण उस संयोजन की अनुकूलता जाँचता है, भविष्य के हर भुगतान की शुद्धता नहीं। [1] [3]

फ़ाइल प्रारूप का संस्करण और Bitcoin लेनदेन का संस्करण अलग अर्थ रखते हैं। v2 में PSBT_GLOBAL_VERSION का मान 2 होना चाहिए, जबकि पुराना PSBT_GLOBAL_UNSIGNED_TX फ़ील्ड नहीं होना चाहिए। अलग अनिवार्य फ़ील्ड PSBT_GLOBAL_TX_VERSION लेनदेन का अपना संस्करण बताता है। इनपुट और आउटपुट की संख्या भी अनिवार्य है। इस विभाजन से जानकारी हर मद के पास रहती है; कार्यक्रम को उसे साझा ढाँचे में भी नहीं खोजना पड़ता। यदि फ़ाइल बनाने वाला आगे का निर्माण दूसरे प्रतिभागियों को सौंपता है, तो BIP 370 उपयुक्त बदलाव-सूचक और कम से कम 2 का लेनदेन संस्करण निर्धारित करने को कहता है। यह कार्य-प्रारूप है, नेटवर्क के नए सहमति नियम नहीं। [1]

हर इनपुट को TXID, यानी पिछले लेनदेन का पहचानकर्ता, और उसमें से खर्च किए जा रहे खास आउटपुट का इंडेक्स चाहिए। केवल TXID पर्याप्त नहीं, क्योंकि एक लेनदेन में कई आउटपुट हो सकते हैं। हर नया आउटपुट satoshi, Bitcoin की सबसे छोटी इकाई, में राशि और scriptPubKey, खर्च की शर्तें बताने वाली स्क्रिप्ट, रखता है। कोई मद जोड़ने पर उसकी वैश्विक गिनती भी बदलनी चाहिए। वैकल्पिक sequence फ़ील्ड इनपुट का एक और नियंत्रण मान रखता है; उसके न होने पर 0xffffffff लिया जाता है। ये निर्माण संबंधी आँकड़े बताते हैं कि लेनदेन कैसे बनेगा। ये खर्च हो रहे UTXO के मूल्य और शर्तों की जानकारी की जगह नहीं लेते, जिनसे उपकरण हस्ताक्षर और शुल्क का सुरक्षित आकलन करता है। [1]

मान लीजिए यान को एक और इनपुट जोड़ना है। कार्यक्रम केवल फ़ाइल अपने पास होने के कारण यह नहीं मान सकता कि ऐसा करने की अनुमति है। PSBT_GLOBAL_TX_MODIFIABLE में बिट 0 इनपुट बदलने और बिट 1 आउटपुट बदलने की अनुमति बताता है। बिट 2, SIGHASH_SINGLE हस्ताक्षर का संकेत देता है, जो इनपुट को उसी क्रम की स्थिति वाले आउटपुट से जोड़ता है। अतिरिक्त मदें डालते समय भी यह जोड़ी बनी रहनी चाहिए। इसलिए लेनदेन बनाने वाला असली हस्ताक्षरों और उनकी सीमाओं की जाँच करता है। ये सूचक साथ काम करने वाले कार्यक्रमों को जानकारी देते हैं; वे क्रिप्टोग्राफ़िक हस्ताक्षर को दरकिनार नहीं कर सकते और किसी अमान्य बदलाव को मान्य नहीं बनाते। [1]

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

हर हस्ताक्षर आगे के बदलाव सीमित करता है। BIP 370 के अनुसार SIGHASH_ANYONECANPAY के बिना इनपुट बदलाव और SIGHASH_NONE के बिना आउटपुट बदलाव बंद करने होते हैं; SIGHASH_SINGLE में बचाकर रखी जाने वाली जोड़ी दर्ज की जाती है। ये नाम हस्ताक्षर की सुरक्षा के अलग दायरे बताते हैं, नए पाठक के लिए मनमाने ढंग से बदलने वाले विकल्प नहीं हैं। जब सभी इनपुट तैयार हों, तो अंतिम रूप देने का चरण ज़रूरी हस्ताक्षर डेटा जोड़ता है और एक्सट्रैक्टर फ़ील्ड से नेटवर्क प्रारूप का लेनदेन बनाता है। प्रसारण के बाद ही नोड उसे परख सकते हैं और कोई माइनर उसे ब्लॉक में शामिल कर सकता है। इसलिए आना और यान प्रस्ताव, हस्ताक्षरित परिणाम और पुष्ट भुगतान में अंतर रखते हैं: केवल PSBT का आदान-प्रदान करना न हस्ताक्षर करना है, न पुष्टि मिलना। [1] [2] [4]