Output Descriptor

ऐना अपने हार्डवेयर वॉलेट को देखने वाला ऐप बदल रही है। वह कंप्यूटर में रिकवरी शब्द डाले बिना अपने पैसे देखने की सुविधा नए ऐप में ले जाना चाहती है। इन रिकवरी शब्दों को Seed Phrase कहते हैं; यह वह बैकअप है जिससे वॉलेट की कुंजियाँ फिर प्राप्त की जा सकती हैं। सार्वजनिक descriptor नए ऐप को बताता है कि कौन-सी सार्वजनिक कुंजियाँ इस्तेमाल करनी हैं और उन्हीं से पहले जैसे पते कैसे बनाने हैं। इसे नया पासवर्ड नहीं, पते बनाने का सटीक निर्देश समझो। सामान्य वॉलेट में प्रोग्राम अक्सर मानक सेटिंग खुद पहचान लेता है। लेकिन किसी अलग तरह की व्यवस्था या Multisig (कई हस्ताक्षर कुंजियों वाला वॉलेट सेटअप) में अंदाजे पर भरोसा नहीं किया जा सकता। Descriptor पैसे नहीं भेजता और पहले मिल चुके भुगतान नहीं बदलता। यह उन नियमों को बताता है जिन्हें रिकवरी में बनाए रखना जरूरी है। [1] [8]

निजी कुंजी से ऐसा डिजिटल हस्ताक्षर बनता है जो पैसे खर्च करने की अनुमति देता है। सार्वजनिक कुंजी उस हस्ताक्षर को जाँच सकती है, लेकिन बना नहीं सकती। सार्वजनिक descriptor में xpub हो सकता है: ऐसी जानकारी जिससे और सार्वजनिक कुंजियाँ निकाली जा सकती हैं, लेकिन हस्ताक्षर नहीं किए जा सकते। यह Watch-only Wallet के काम आती है, जो भुगतान देखता है पर खुद उन्हें भेज नहीं सकता। फिर भी निजता के लिए इस निर्यात को सँभालकर रखना चाहिए, क्योंकि इससे तुम्हारे कई पते और उनका इतिहास आपस में जुड़ सकते हैं। किसी दूसरे descriptor में xprv, यानी विस्तारित निजी कुंजी, या WIF, यानी एक निजी कुंजी लिखने का प्रारूप हो सकता है। तब यह गुप्त सामग्री है, जो संबंधित शर्तें पूरी होने पर पैसे खर्च करने की क्षमता दे सकती है। इसे ऑनलाइन जाँच साइट पर मत भेजो और सामान्य नोट समझकर मत रखो। सार्वजनिक कॉन्फ़िगरेशन हस्ताक्षर करने के लिए जरूरी बैकअप की जगह नहीं लेता। [1] [8]

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

तीन कुंजियों में से दो हस्ताक्षर माँगने वाले वॉलेट के लिए रिकवरी शब्दों के दो सेट और यह याद होना कि ‘यह तीन में से दो वाली व्यवस्था थी’ पर्याप्त नहीं है। सही खर्च-शर्तें दोबारा बनाने के लिए तीनों कुंजियों की सार्वजनिक जानकारी, उनके derivation के नियम और सटीक स्क्रिप्ट प्रकार चाहिए। स्क्रिप्ट उन शर्तों को दर्ज करती है जिन्हें पूरा करने पर पैसे खर्च किए जा सकते हैं। तकनीकी रूप multi(k,...) में लिखी गई कुंजियों का क्रम इस्तेमाल होता है; k जरूरी हस्ताक्षरों की संख्या है। sortedmulti(k,...) हर स्क्रिप्ट बनाते समय निकाली गई सार्वजनिक कुंजियों को उनके बाइट के क्रम में लगाता है। ये अलग नियम हैं, एक-दूसरे की जगह इस्तेमाल होने वाले नाम नहीं। इसलिए पूरा कॉन्फ़िगरेशन निर्यात रखो और हस्ताक्षर के लिए जरूरी कुंजियों के बैकअप अलग से सुरक्षित करो। केवल डिवाइसों के नामों की सूची काफी नहीं है। [2] [8]

# के बाद आठ अक्षरों का checksum हो सकता है, जिसकी व्यवस्था BIP380 में दी गई है। यह जाँच मान प्रोग्राम को नकल करते समय हुई कई गलतियाँ पहचानने देता है। लेकिन यह लेखक का हस्ताक्षर, एन्क्रिप्शन या इस बात का प्रमाण नहीं कि descriptor तुम्हारा है। जो जानबूझकर अपनी कुंजियाँ डालता है, वह नया सही checksum भी निकाल सकता है। इसलिए टेक्स्ट की जाँच के साथ पते और कॉन्फ़िगरेशन का स्रोत भी जाँचना चाहिए। अगर ऐप checksum की गलती बताए, तो पहले मूल निर्यात दोबारा प्राप्त करो। सिर्फ नया checksum बना देने से पहले से बिगड़ा हुआ टेक्स्ट भी जाँच में स्वीकार हो सकता है। [1]

कुंजी से पहले [fingerprint/path] हो सकता है, जिसे key origin या कुंजी के स्रोत की जानकारी कहते हैं। Fingerprint शुरुआती कुंजी का छोटा पहचान-चिह्न है; path वह रास्ता है जिससे उसके बाद लिखी कुंजी निकाली गई थी। इससे हस्ताक्षर करने वाले डिवाइस को सही कुंजी खोजने में मदद मिलती है। xpub के बाद अलग-अलग पते निकालने के लिए एक और रास्ता हो सकता है। इन दोनों हिस्सों के काम अलग हैं; ये सिर्फ खाते के लेबल नहीं हैं। अलग कुंजियों का fingerprint संयोग से समान हो सकता है, इसलिए इससे डिवाइस की पहचान प्रमाणित नहीं होती। सार्वजनिक निर्यात Hardened Derivation के चरण से भी मनमाने ढंग से आगे नहीं बढ़ सकता, क्योंकि उस चरण में निजी जानकारी चाहिए। निर्यात करने वाले ऐप को सही स्तर की कुंजी चुननी होती है। [1]

/* में तारे का मतलब क्रम से संख्या भरना है, जैसे 0, 1 और 2। ऐसा ranged descriptor केवल एक पता नहीं बताता; किसी खास काम के लिए प्रोग्राम तय करता है कि कौन-से इंडेक्स की सीमा पर काम करना है। अगर ऐप समर्थन करता हो, तो BIP389 का <0;1> रूप दो शाखाएँ शामिल कर सकता है, आम तौर पर प्राप्ति और चेंज के लिए। लेकिन descriptor खुद इस्तेमाल किए गए पतों की सूची या अगली खाली संख्या नहीं रखता। Gap limit, यानी लगातार कितने ऐसे पते मिलने पर खोज रोकनी है जो कभी इस्तेमाल नहीं हुए, भी अपने-आप अभिव्यक्ति का हिस्सा नहीं होता। इस्तेमाल न होने का मतलब है कि पते का कोई लेनदेन इतिहास नहीं है। जिस पते पर पैसे आए और बाद में खर्च हो गए, वह इस्तेमाल न किया गया पता नहीं है। इसलिए रिकवरी में वॉलेट की स्थिति की जानकारी और पर्याप्त बड़ी सीमा में खोज की जरूरत पड़ सकती है। [5] [6] [9]

लेनदेन के आउटपुट में scriptPubKey होता है, वह स्क्रिप्ट जो तय करती है कि बाद में उसे कैसे खर्च किया जा सकेगा। Descriptor बताता है कि यह स्क्रिप्ट कैसे बनाई जाए। wpkh(KEY) एक कुंजी वाले Native SegWit का विवरण है; यहाँ KEY केवल उदाहरण का स्थानधारक है, असली कुंजी नहीं। इसे sh(wpkh(KEY)) में लपेटने से आउटपुट का प्रारूप और पता बदल जाता है, भले ही कुंजी वही रहे। अन्य अभिव्यक्तियों में pk(), pkh(), wsh(), addr() और raw() हैं। ये एक-दूसरे की जगह इस्तेमाल होने वाले विकल्प नहीं हैं: उदाहरण के लिए addr() किसी ज्ञात पते का विवरण देता है, लेकिन खर्च करने के लिए गायब जानकारी खुद नहीं जोड़ता। यह हिस्सा सेटिंग के लिए संदर्भ है, शुरुआती पाठक से descriptor हाथ से लिखने की अपेक्षा नहीं। [1] [8]

Taproot आउटपुट कुंजी के हस्ताक्षर से खर्च हो सकता है, या उसमें शामिल स्क्रिप्ट शर्तों से, अगर वे मौजूद हों। tr(KEY) एक आंतरिक कुंजी बताता है, जिसमें खर्च के लिए उपयोगी स्क्रिप्ट शाखा नहीं होती; tr(KEY,TREE) स्क्रिप्टों का पेड़ जोड़ता है। इसलिए केवल कुंजियों की सूची बचाना पर्याप्त नहीं है। पेड़ में स्क्रिप्टों को कैसे समूहित किया गया है, यह भी मायने रखता है। समूह बदलने से उनका संयुक्त हैश, Merkle root, और अंतिम पता बदल सकता है, भले ही अलग-अलग शर्तें वही रहें। हालाँकि शाखाओं की हर अदला-बदली नतीजा नहीं बदलती। Miniscript शर्तें लिखने और समझने में मदद करता है, जबकि multi_a, Taproot की स्क्रिप्ट भाषा Tapscript में कई हस्ताक्षर व्यक्त करता है। इनमें से कोई भी अकेले पूरे कॉन्फ़िगरेशन निर्यात की जगह नहीं लेता। [3] [8]

RPC एक इंटरफ़ेस है जिससे किसी दूसरे प्रोग्राम या कमांड लाइन के ज़रिए सॉफ़्टवेयर को निर्देश दिए जा सकते हैं। Bitcoin Core 29 में RPC कमांड getdescriptorinfo अभिव्यक्ति का विश्लेषण करता है। यह निजी कुंजियों के बिना सार्वजनिक रूप और checksum, isrange, issolvable तथा hasprivatekeys फ़ील्ड लौटाता है। आखिरी फ़ील्ड बताता है कि इनपुट में निजी कुंजी थी या नहीं; issolvable का मतलब यह नहीं कि हस्ताक्षर के लिए जरूरी गुप्त कुंजियाँ तुम्हारे पास हैं। deriveaddresses से निकाले गए पतों की तुलना की जा सकती है। आयात करते समय importdescriptors, timestamp, active, internal, range और next_index भी लेता है: इतिहास की खोज का शुरुआती समय, कॉन्फ़िगरेशन सक्रिय है या नहीं, वह आंतरिक चेंज के लिए है या नहीं, सीमा और अगले पते का इंडेक्स। Rescan का मतलब चेन में लेनदेन फिर से खोजना है। बहुत देर का timestamp पुराने भुगतान छोड़ सकता है; descriptor बदलने से वे न कहीं चले जाते हैं, न मिटते हैं। आयात के बाद वॉलेट का नया बैकअप चाहिए। इन कमांड का इस्तेमाल अपने भरोसेमंद कंप्यूटर पर स्थापित Bitcoin Core में करो, किसी दूसरे की वेबसाइट के फ़ॉर्म में नहीं। [5] [7] [8]