Gap Limit

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

यहाँ अप्रयुक्त का मतलब क्या है? ऐसा पता नहीं जिस पर अभी पैसे नहीं हैं। अन्ना ने भुगतान पाने के बाद उसे पूरा खर्च कर दिया हो सकता है। शेष शून्य हो जाएगा, लेकिन लेनदेन इतिहास बना रहेगा और खोज में पता इस्तेमाल किया हुआ माना जाएगा। इसलिए BIP 44 सिर्फ वर्तमान शेष नहीं, इतिहास देखता है। हर खाली पते को कभी इस्तेमाल न हुआ मानने से बहाली बहुत जल्दी रुक सकती है। बहुत पहले खर्च किया गया भुगतान भी बहाल वॉलेट की जाँच में उपयोगी है। [1]

BIP 44 एक मानक है जो पदानुक्रम वाले वॉलेट में खातों और पतों का संगठन बताता है। ऐसे वॉलेट में कुंजियाँ और पते अलग शाखाओं वाले पेड़ की तरह व्यवस्थित होते हैं। इसका Address gap limit नियम बाहरी प्राप्ति शाखा की खोज के लिए 20 की सीमा रखता है। यह शाखा भुगतान प्राप्त करने वाले पतों की कतार है। सीमा से आगे पता बनाते समय सॉफ्टवेयर को चेतावनी देनी चाहिए। यह बहाली की व्यवस्था है, नेटवर्क द्वारा लेनदेन स्वीकार करने का सर्वसम्मति नियम नहीं। दूसरे वॉलेट अलग सेटिंग या खोज प्रक्रिया अपना सकते हैं। इसका अर्थ एक ही प्राप्ति पते को हमेशा दोहराने की सलाह भी नहीं है। [1]

मूल वॉलेट को क्रम में बहुत आगे बनाए गए पते भी पता हो सकते हैं। केवल कुंजियों के बैकअप से बहाली करने वाला नया प्रोग्राम शायद न जानता हो कि आप पहले कहाँ तक गए थे। Electrum का दस्तावेज स्पष्ट चेतावनी देता है कि Gap Limit के आगे के पते सामान्य बहाली में अपने आप नहीं मिल सकते। उसमें सीमा बढ़ाने या इस्तेमाल की गई जगह तक और पते निकालने का तरीका बताया गया है। सही सेटिंग सॉफ्टवेयर और वॉलेट के प्रकार पर निर्भर करती है। FAQ में डिफॉल्ट 20 का उल्लेख Electrum 2.0 के लिए है, सभी वर्तमान वॉलेट के लिए नहीं। [2]

वॉलेट को व्यवस्थित पेड़ की तरह सोचिए। खाते धन के अलग समूह रखते हैं और हर खाते में पतों की अलग शाखाएँ हो सकती हैं। BIP 44 में change=0 प्राप्ति शाखा और change=1 अपने बचे हुए पैसे की शाखा है। यह वह राशि है जो भुगतान के बाद भेजने वाले की ही रहती है। खातों की खोज खाते 0 की बाहरी शाखा से शुरू होती है। इतिहास मिले तो अगला खाता खोजा जाता है; बिना इतिहास वाला पहला खाता मिलने पर खातों की खोज रुक जाती है। इसलिए मानक कहता है कि पिछले खाते में इतिहास न हो तो नया खाता न बनाएँ। एक शाखा में पतों का खाली अंतर और बीच में छोड़ा गया खाली खाता अलग समस्याएँ हैं। एक सीमा बढ़ाने से अपने आप तय नहीं होता कि प्रोग्राम किन अन्य खातों में खोजेगा। [1]

BIP 32 कुंजियों के निर्धारक व्युत्पादन को बताता है: वही शुरुआती जानकारी और वही रास्ता हमेशा वही कुंजियाँ बनाते हैं। Derivation Path इस पेड़ में आगे बढ़ने का रास्ता है। स्क्रिप्ट के प्रकार, यानी खर्च करने के नियमों के साथ मिलकर यह तय करता है कि वॉलेट कौन से पते देखेगा। सही Seed Phrase, अर्थात बैकअप के शब्द, बहाली की जरूरी जानकारी का केवल एक हिस्सा हैं। BIP 39 में वैकल्पिक passphrase भी seed, यानी कुंजियाँ निकालने के शुरुआती रहस्य, की गणना में शामिल होती है। passphrase ऐप के पासवर्ड से अलग एक अतिरिक्त गुप्त पाठ है। दूसरी passphrase दूसरे वॉलेट तक ले जाती है; Gap Limit बढ़ाने से यह ठीक नहीं होता। निजी कुंजी एक गुप्त संख्यात्मक मान है, जिससे वॉलेट पैसे खर्च करने की अनुमति देने वाला डिजिटल हस्ताक्षर बनाता है। अधिक जानना चाहें तो xpub एक विस्तारित सार्वजनिक कुंजी है जिससे आगे की सार्वजनिक कुंजियाँ निकलती हैं। इससे पते और भुगतान देखे जा सकते हैं, लेकिन केवल इसके आधार पर खर्च की अनुमति नहीं दी जा सकती। वह अकेले hardened चरण पार नहीं कर सकती, जिसके लिए मूल की निजी कुंजी चाहिए। खोज बढ़ाने से यह अनुपस्थित क्षमता नहीं मिल जाती। [4] [5] [6]

Bitcoin Core 29.0 नोड के प्रोग्रामिंग इंटरफेस RPC के माध्यम से importdescriptors देता है। Descriptor बताता है कि कुंजियों से खर्च की शर्तें और निगरानी वाले पते कैसे बनते हैं। range निकाले जाने वाले इंडेक्स की सीमा है; वह खाली अंतर पर रुकने का नियम नहीं। सक्रिय descriptor के लिए next_index अगला पता बनाने का इंडेक्स तय करता है। timestamp तय करता है कि किस समय से लेनदेन खोजना है। now उन आउटपुट के लिए है जिनके बारे में मालूम है कि वे कभी इस्तेमाल नहीं हुए; यह पुराने भुगतानों की बहाली का विकल्प नहीं। दस्तावेज में आयात किए गए descriptors के सबसे पुराने timestamp से दो घंटे पहले तक के ब्लॉक और स्थानीय अपुष्ट लेनदेन संग्रह Mempool भी शामिल हैं। इसलिए सही निकला पता भी सूची से छूट सकता है अगर संबंधित अवधि नहीं खोजी गई। [3]

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