Watch-only Wallet से आप भुगतान और शेष राशि देख सकते हैं, लेकिन इसमें खर्च करने वाली निजी कुंजियाँ नहीं होतीं। यह भुगतान का प्रस्ताव भी तैयार कर सकता है, जिस पर दूसरे उपकरण या प्रोग्राम को हस्ताक्षर करने होंगे। इससे फोन या कंप्यूटर पर वॉलेट देखना और कुंजियाँ अलग रखना संभव होता है। केवल watch-only लिखा होने से यह पता नहीं चलता कि कुंजियाँ किसके पास हैं या दिखाई गई जानकारी सही है या नहीं।
एलिस अपनी कुंजियाँ हार्डवेयर वॉलेट में रखती है और फोन से देखना चाहती है कि भुगतान आया या नहीं। वह फोन में वॉलेट की सार्वजनिक सेटिंग लाती है, बैकअप शब्द नहीं। उनसे ऐप संबंधित पते पहचानकर नेटवर्क में उनके भुगतान खोज लेता है। एलिस 20 000 sat (बिटकॉइन की सबसे छोटी इकाइयाँ) का भुगतान और उसकी पुष्टियाँ देख सकती है, भले ही हस्ताक्षर करने वाला उपकरण घर पर बंद पड़ा हो। इससे फोन को पैसे खर्च करने का अधिकार नहीं मिला। इसी तरह व्यापारी अपनी लेखाकार को कुंजियाँ दिए बिना भुगतान देखने की सुविधा दे सकता है। महत्त्वपूर्ण यह है कि वास्तव में क्या आयात किया गया: Seed Phrase, यानी कुंजियाँ वापस पाने वाले बैकअप शब्द, डालने से यह अलगाव खत्म हो जाएगा। [12]
निगरानी ऐप में किसी दूसरे व्यक्ति का सार्वजनिक पता भी जोड़ा जा सकता है। इसलिए स्क्रीन पर रकम दिखना इस बात का प्रमाण नहीं कि उपयोगकर्ता उसे खर्च कर सकता है, सभी कर्ज चुकाने की बात तो दूर है। ऐप मिले हुए UTXO जोड़ता है, यानी पुराने भुगतानों के ऐसे आउटपुट जो अभी खर्च नहीं हुए। उसे वही मिलता है जो आयात किए डेटा और उपलब्ध इतिहास से मेल खाता है। छूटे हुए पते, अधूरी खोज या अविश्वसनीय सर्वर से तस्वीर अधूरी हो सकती है। केवल शून्य दिखने का अर्थ बिटकॉइन खो जाना नहीं है; पहले निगरानी का दायरा और डेटा का स्रोत जाँचें। [8] [9]
जब एलिस भुगतान करना चाहती है, ऐप उपलब्ध UTXO चुनकर प्राप्तकर्ता, राशि और शुल्क तैयार करता है। किसी इनपुट में बची रकम अपने वॉलेट में वापस आ सकती है; इसे change कहते हैं। ये विवरण PSBT में भेजे जा सकते हैं, जो BIP174 में बताया गया आंशिक रूप से हस्ताक्षरित बिटकॉइन ट्रांज़ैक्शन का प्रारूप है। अलग उपकरण को अपना UTXO डेटाबेस रखे बिना हस्ताक्षर के लिए आवश्यक जानकारी मिल जाती है। एलिस को उसकी भरोसेमंद स्क्रीन पर वास्तविक प्राप्तकर्ता, राशि, शुल्क और वापस आने वाली रकम जाँचनी चाहिए। हैक हुआ ऐप उसकी इच्छा से अलग भुगतान तैयार कर सकता है। sighash सेटिंग भी महत्त्वपूर्ण है: यह बताती है कि हस्ताक्षर ट्रांज़ैक्शन के किन हिस्सों को कवर करता है। जाँच और हस्ताक्षर के बाद ही मंज़ूर प्रस्ताव तथा वॉलेट के नियमों से मेल खाने वाला अंतिम ट्रांज़ैक्शन नेटवर्क में भेजना चाहिए। [2] [10]
विस्तारित सार्वजनिक कुंजी, या xpub, वॉलेट की एक शाखा में और सार्वजनिक कुंजियाँ निकाल सकती है; अकेले उससे भुगतान पर हस्ताक्षर नहीं हो सकते। फिर भी जिसे वॉलेट के नियमों के साथ xpub मिल जाए, वह उससे निकाले जा सकने वाले पते, पुराने और भविष्य के भुगतान तथा शेष राशि आपस में जोड़ सकता है। यह एक भुगतान के लिए एक पता देने से कहीं अधिक जानकारी है। बाहरी सर्वर भी ऐप के बार-बार भेजे गए अनुरोधों से ऐसी तस्वीर बना सकता है। अपना Full Node, जो खुद ब्लॉकचेन की जाँच करता है, इस खुलासे को सीमित करता है। एन्क्रिप्टेड या दूसरे निजी कनेक्शन से भी पूछताछ गंतव्य सर्वर से नहीं छिपती। केवल ज़रूरी खाता निर्यात करें, प्रतियाँ सीमित रखें और पतों को नाम या भुगतान के उद्देश्य से जोड़ने वाले लेबल भी सुरक्षित रखें। [1] [13] [14]
आगे के हिस्से सेटअप और रिकवरी के लिए तकनीकी संदर्भ हैं। स्क्रिप्ट खर्च की शर्तें तय करती है; Output Descriptor उन नियमों और पते निकालने की जानकारी का रिकॉर्ड है। HD Wallet, seed से कुंजियों का पेड़ बनाता है। seed वह शुरुआती गुप्त डेटा है जिससे ये कुंजियाँ निकाली जाती हैं। non-hardened व्युत्पत्ति में xpub से और सार्वजनिक कुंजियाँ निकल सकती हैं, जबकि hardened व्युत्पत्ति के लिए निजी कुंजी चाहिए। Multisig आवश्यक हस्ताक्षरों की एक तय संख्या जोड़ता है। एक पता आयात करने से केवल उसकी स्क्रिप्ट पर नज़र रहती है, भविष्य के प्राप्ति और बचे हुए धन के पते पर नहीं। सार्वजनिक कुंजी अलग स्क्रिप्ट प्रकारों को तभी कवर करती है जब प्रोग्राम उन्हें स्पष्ट रूप से निकाले। खाते का xpub, non-hardened वंशज निकाल सकता है, लेकिन P2PKH, SegWit, Taproot, आंतरिक शाखा या Multisig में आवश्यक हस्ताक्षरों की संख्या नहीं बताता। डिस्क्रिप्टर यह संदर्भ जोड़ता है। उसे हस्ताक्षर उपकरण के सही खाते से सही नेटवर्क और स्क्रिप्ट प्रकार के साथ निर्यात करें; व्युत्पत्ति के पथ, यानी शुरुआती कुंजी से आगे बढ़ने वाले चरणों के क्रम का अनुमान न लगाएँ। [1] [4] [7]
HD वॉलेट आम तौर पर प्राप्ति शाखा /0/* और change, यानी खर्च के बाद वापस बची राशि के लिए आंतरिक /1/* अलग रखते हैं। आंतरिक शाखा न होने पर खर्च के बाद कुछ धन गायब दिख सकता है। range निकाले जाने वाले पतों की सीमा है; यह छोटी हो तो भुगतान छूट सकते हैं। next_index अगला बनने वाला पता तय करता है। दो प्रोग्रामों में इसका मान अलग होने से पता दोबारा इस्तेमाल हो सकता है। सक्रिय डिस्क्रिप्टर, सीमाएँ और सूचकांक मिलाकर रखें। प्राप्ति का पता हस्ताक्षर उपकरण की स्क्रीन पर जाँचें: मैलवेयर विश्वसनीय शेष राशि दिखाते हुए भी पता बदल सकता है। [6] [9]
Bitcoin Core का importdescriptors दोबारा खोज की शुरुआत तय करने के लिए timestamp इस्तेमाल करता है। now पुराना इतिहास छोड़ता है; 0, Genesis Block से खोज का अनुरोध करता है। range की सीमा और पुराने ब्लॉक उपलब्ध होना भी महत्त्वपूर्ण है। active तय करता है कि डिस्क्रिप्टर से नए पते बनाए जाएँगे या नहीं; internal वॉलेट के भीतर के आउटपुट, जैसे वापस आने वाली बची रकम, को चिह्नित करता है। पुराने ब्लॉक हटाने वाले नोड के पास शायद ज़रूरी इतिहास न हो। Rescan केवल मौजूदा लेनदेन खोजता है। पहले उपयोग की तारीख या ब्लॉक ऊँचाई रखें और बहाली को ज्ञात पतों तथा लेनदेन से मिलाएँ, सिर्फ स्क्रीन के शून्य से नहीं। [9] [10]
BIP380 आउटपुट स्क्रिप्ट के समुच्चयों की भाषा बताता है। उदाहरण wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum में स्क्रिप्ट प्रकार, मुख्य कुंजी की पहचान-छाप, मूल पथ, खाते की सार्वजनिक कुंजी, शाखा, बदलता सूचकांक और चेकसम हैं। यह सीधे आयात करने योग्य वैध डेटा नहीं है। Taproot, BIP386 के अनुसार tr() इस्तेमाल करता है; BIP389 एक अभिव्यक्ति में कई पथ देता है। चेकसम नकल की गलतियाँ पकड़ता है, लेखक की पहचान प्रमाणित नहीं करता। xprv वाला डिस्क्रिप्टर गुप्त कुंजी रखता है और निगरानी समन्वयक में नहीं जाना चाहिए। [4] [5] [6] [7]
BIP32 एक महत्त्वपूर्ण अपवाद बताता है: ऊपरी स्तर के (parent) xpub के साथ किसी ऐसे वंशज की निजी कुंजी मिल जाए जो केवल non-hardened चरणों से निकला है, तो उसी ऊपरी स्तर की निजी कुंजी निकाली जा सकती है। अकेला xpub पर्याप्त नहीं; दोनों का साथ खतरनाक है। निर्यात किए खाते के ऊपर hardened चरण हमले को उस सीमा के पार जाने से रोकता है। निगरानी वॉलेट, उसके डेटाबेस या साथ की PSBT फ़ाइलों में कभी xprv, seed या निजी कुंजियाँ न डालें। [1]
Multisig की निगरानी के लिए आवश्यक हस्ताक्षरों की संख्या, स्क्रिप्ट प्रकार, हर सह-हस्ताक्षरकर्ता का xpub, कुंजियों का मूल और क्रम तथा दोनों पता शाखाएँ चाहिए। केवल एक xpub पर्याप्त नहीं। seed सुरक्षित हों तब भी डिस्क्रिप्टर खोने से बहाली कठिन हो सकती है; दूसरा क्रम या स्क्रिप्ट का आवरण अलग पते दे सकता है। सभी हस्ताक्षर उपकरणों पर नियम और नमूना पता जाँचें। चेकसम वाला डिस्क्रिप्टर या मानक विन्यास रखें और याद रखें कि इससे सह-हस्ताक्षरकर्ताओं के संबंध भी सामने आते हैं। [4] [11]
निजी कुंजियों से अलग दोनों शाखाओं के डिस्क्रिप्टर, कुंजियों का मूल, नेटवर्क, निर्माण की तारीख या ऊँचाई, सीमाएँ, सूचकांक, लेबल और Multisig नियम रखें। BIP329 लेबल ले जाता है; डिस्क्रिप्टर या इतिहास की जगह नहीं लेता। अलग प्रोफ़ाइल या परीक्षण नेटवर्क पर बहाली जाँचें: सार्वजनिक विन्यास आयात करें, इतिहास खोजें, दोनों शाखाओं के पुराने पते और अपेक्षित UTXO मिलाएँ, PSBT तैयार करके तय उपकरण से हस्ताक्षर करें। प्रसारण से पहले नतीजा जाँचें। Watch-only निगरानी और तैयारी के लिए है, खर्च का अधिकार देने के लिए नहीं। [3] [9] [12]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Extended Public Key (xpub), वॉलेट, Cold Storage, Output Descriptor, PSBT, Bitcoin. इस प्रविष्टि का उल्लेख यहाँ भी है HD Wallet, Cold Storage, Extended Public Key (xpub), Output Descriptor.