बिटकॉइन पता

ऐलिस को बॉब को पैसे देने हैं। बॉब अपने वॉलेट में प्राप्त करें खोलता है, दिख रहा पता जाँचता है और उसे टेक्स्ट या QR कोड के रूप में भेजता है। ऐलिस उसे अपने वॉलेट में पढ़वाती है और भेजने से पहले प्राप्तकर्ता तथा रकम जाँचती है। पते के हर अक्षर का अर्थ समझना ज़रूरी नहीं; ऐप यह काम करता है। वॉलेट पते से वह शर्त बनाता है जिसे बाद में पैसे खर्च करने के लिए पूरा करना होगा। आम तौर पर इसके लिए सही निजी कुंजी से हस्ताक्षर चाहिए। ट्रांज़ैक्शन इस शर्त को scriptPubKey नाम की स्क्रिप्ट में दर्ज करता है। उसमें रकम और स्क्रिप्ट होती है, पते का परिचित टेक्स्ट नहीं। इसलिए पता भुगतान की जानकारी देने का सुविधाजनक तरीका है, सिक्के रखने का डिब्बा नहीं। [1] [3]

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

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

वॉलेट कुंजियाँ संभालता है, उन भुगतानों को खोजता है जिन्हें वह खर्च कर सकता है और उनका कुल दिखाता है। इसलिए शेष रकम कई पतों से आ सकती है। सामान्य HD Wallet एक साझा आधार से कुंजियों के पूरे समूह बनाता है; नया पता लेने का मतलब दूसरा वॉलेट खोलना नहीं है। भुगतान करते समय ऐप बची रकम अपने Change Address, यानी बचे पैसे वापस पाने के पते, पर भी भेज सकता है। लेकिन केवल पते बहाली के लिए पर्याप्त नहीं हैं। बैकअप से ज़रूरी कुंजियाँ और उनके इस्तेमाल की शर्तें वापस मिलनी चाहिए। कई वॉलेट इसके लिए Seed Phrase, यानी बहाली के शब्दों का समूह, इस्तेमाल करते हैं; जटिल व्यवस्थाओं में और जानकारी भी चाहिए हो सकती है। भुगतान करने वाले को वे शब्द या आपकी निजी कुंजियाँ कभी नहीं चाहिए। [10] [14]

QR कोड जानकारी दिखाने का तरीका भर है। उसमें केवल पता हो सकता है या bitcoin: से शुरू होने वाला भुगतान अनुरोध, जिसमें रकम, प्राप्तकर्ता का लेबल या संदेश भी जुड़ा हो। इस तरीके का वर्णन BIP21 ने किया था और BIP321 इसे विस्तार देता है। मंजूरी देने से पहले देखें कि वॉलेट ने वास्तव में क्या पढ़ा है। Lightning Network के अनुरोध, जैसे एक भुगतान की invoice या ऐसा offer जिससे हर बार नई invoice माँगी जा सकती है, अलग भुगतान प्रक्रिया अपनाते हैं; Lightning Address ऐसा अनुरोध पाने को आसान बनाता है। कुछ अनुरोध भुगतान के कई तरीके देते हैं। इसी तरह संदेश पर डिजिटल हस्ताक्षर अपने-आप पहचान की पुष्टि नहीं है: BIP322 दिखा सकता है कि किसी स्क्रिप्ट की शर्तें पूरी की जा सकती हैं, लेकिन अकेले इससे कानूनी पहचान या किसी भी बिल की मंजूरी सिद्ध नहीं होती। [15] [16] [17]

Base58Check संस्करण के एक बाइट को payload कहलाने वाले डेटा से जोड़ता है। फिर SHA256(SHA256(version || payload)) के पहले चार बाइट जोड़कर नतीजे को Base58 वर्णमाला में लिखता है। mainnet पर 0x00 का अर्थ P2PKH और 0x05 का P2SH है; इसी कारण पते आम तौर पर 1 या 3 से शुरू होते हैं। परीक्षण नेटवर्क दूसरे संस्करण इस्तेमाल करते हैं। आसानी से भ्रम पैदा करने वाले 0, O, I और l वर्णमाला में नहीं रखे गए हैं। यह 32-बिट चेकसम टाइपिंग की कई गलतियाँ पकड़ता है, लेकिन प्राप्तकर्ता की पहचान प्रमाणित नहीं करता। [2] [3]

नेटिव SegWit का निरूपण mainnet के लिए bc या testnet के लिए tb प्रीफ़िक्स, विभाजक 1, witness संस्करण और 5-बिट समूहों में बँटे डेटा से बनता है। अंत में चेकसम के 6 अक्षर होते हैं। BIP173 ने Bech32 पेश किया; कुछ तरह के अक्षर जोड़ने और हटाने पर कमजोरी मिलने के बाद BIP350 ने संस्करण 0 के लिए Bech32 रखा और संस्करण 1–16 के लिए Bech32m तय किया। अंग्रेज़ी अक्षर सभी छोटे या सभी बड़े हो सकते हैं, दोनों को मिलाना मना है। एन्कोडिंग की सीमा 90 अक्षर है। सही निरूपण भी गलत नेटवर्क या असमर्थित संस्करण का हो सकता है। [7] [8]

P2PKH और P2WPKH सार्वजनिक कुंजी के 20-बाइट HASH160 को संदर्भित करते हैं। P2SH में redeemScript का HASH160 और P2WSH में witnessScript का SHA256 इस्तेमाल होता है। इसलिए SegWit v0, 20-बाइट P2WPKH और 32-बाइट P2WSH को पहचानता है। BIP341 का P2TR अलग है: उसके संस्करण 1 प्रोग्राम में संशोधित 32-बाइट x-only आउटपुट कुंजी Q होती है, सामान्य प्राप्ति कुंजी का हैश नहीं। Q की गणना में अतिरिक्त स्क्रिप्ट के पेड़ का रूट भी शामिल किया जा सकता है। इससे कुंजी और खर्च की वे शर्तें क्रिप्टोग्राफिक रूप से जुड़ जाती हैं। इसलिए अकेले पते से खर्च करने के सभी तरीके नहीं पता चलते। [6] [9]

शुरुआती बिटकॉइन आउटपुट अक्सर सीधे सार्वजनिक कुंजी को भुगतान करते थे। P2PKH ने कुंजी का खुलासा खर्च करने के समय तक टाल दिया। BIP13 और BIP16 ने P2SH के ज़रिए जटिल स्क्रिप्ट का हैश देना संभव बनाया। BIP141 ने संस्करण वाले witness प्रोग्राम, BIP173 ने Bech32, और BIP341 के साथ BIP350 ने Bech32m वाला Taproot फ़ॉर्मैट जोड़ा। अलग रूप के पीछे सत्यापन की अलग शर्तें हैं। प्रीफ़िक्स हाथ से बदलकर पते को ‘बदलने’ की कोशिश न करें: इससे अलग या खर्च न हो सकने वाला आउटपुट बन सकता है। कुछ गैर-मानक स्क्रिप्ट और शुरुआती pay-to-pubkey आउटपुट का सामान्य मानक पता नहीं होता। [4] [5] [6] [7] [8] [9] [3]

BIP32 के अनुसार HD Wallet एक साझा मूल से कई कुंजियाँ व्युत्पन्न करता है। पथ आउटपुट के प्रकार अलग करते हैं: BIP44 में P2PKH के लिए उद्देश्य 44', BIP84 में P2WPKH के लिए 84' और BIP86 में एक कुंजी वाले P2TR के लिए 86' होता है। इसके बाद कॉइन का प्रकार (coin type), खाता, प्राप्ति या बाकी रकम की शाखा और पते का इंडेक्स आते हैं। अकेली Seed Phrase सभी पथ, खाते और Multisig नियम तय नहीं कर सकती। Output Descriptor कुंजियों का मूल और स्क्रिप्ट की बनावट भी दर्ज करता है। बहाली में वास्तविक धन मिलना चाहिए, केवल कोई जाना-पहचाना पता फिर दिखना पर्याप्त नहीं है। [10] [11] [12] [13] [14]

P2PKH और P2WPKH में शुरुआत में आम तौर पर कुंजी का हैश दिखता है; खर्च करने पर सार्वजनिक कुंजी खुलती है। P2SH और P2WSH इस्तेमाल किए गए redeemScript या witnessScript को उजागर करते हैं। Taproot के आउटपुट में संशोधित सार्वजनिक कुंजी पहले से होती है। key path से खर्च करते समय आम तौर पर Schnorr Signature जुड़ता है, जबकि script path में चुनी गई स्क्रिप्ट, control block और Merkle पथ खुलते हैं; इस्तेमाल न हुई शाखाएँ छिपी रह सकती हैं। इसलिए यह कहना गलत है कि हर पता सार्वजनिक कुंजी छिपाता है। [6] [9]