Bitcoin मूल बातें

Bitcoin पता प्रकार समझाए गए

लेगेसी, नेस्टेड SegWit, नेटिव SegWit और Taproot एड्रेस प्रारूपों, उपसर्गों, संगतता और सुरक्षा सीमाओं की तुलना करें।.

सीधा उत्तर

दो Bitcoin पते दोनों BTC प्राप्त कर सकते हैं और फिर भी अंतर्निहित अलग-अलग लेनदेन संरचनाएं बना सकते हैं। एक मेननेट पता जो से शुरू होता है 1, एक जो 3, एक bc1q एड्रेस और एक bc1p एड्रेस सभी मान्य गंतव्य हो सकते हैं, लेकिन वे आवश्यक रूप से एक ही स्क्रिप्ट, एन्कोडिंग या भविष्य की खर्च शर्त का प्रतिनिधित्व नहीं करते हैं।.

यह अंतर आसानी से छूट सकता है क्योंकि वॉलेट एक एड्रेस को एकल स्ट्रिंग के रूप में प्रस्तुत करता है। इसके नीचे, एड्रेस सॉफ्टवेयर को बताता है कि लेनदेन आउटपुट कैसे बनाया जाए। एक बार जब वह आउटपुट पुष्टि हो जाता है, तो यह एक UTXO बन जाता है जिसे बाद में उस आउटपुट द्वारा एन्कोड किए गए स्क्रिप्ट नियमों के अनुसार खर्च किया जाना चाहिए।.

व्यावहारिक प्रश्न इसलिए केवल यह नहीं है कि “कौन सा उपसर्ग नया है?” यह है कि क्या पता इच्छित Bitcoin नेटवर्क से संबंधित है, यह किस आउटपुट प्रकार का प्रतिनिधित्व करता है, क्या भेजने वाला सॉफ्टवेयर उस प्रारूप का समर्थन करता है, और भुगतान अधिकृत करने से पहले पता आपको क्या बता सकता है—और क्या नहीं बता सकता।.

Bitcoin पता क्या दर्शाता है

Bitcoin पता बैंकिंग अर्थ में खाता नहीं है। इसमें बिटकॉइन नहीं होता, निजी कुंजी नहीं होती, या वॉलेट शेष का पूरा दृश्य प्रदान नहीं करता। यह एक मानव-पठनीय एन्कोडिंग है जो वॉलेट को एक विशेष लेनदेन आउटपुट बनाने में मदद करती है।.

सरलीकृत संबंध है:

Bitcoin address
        ↓
Address decoding
        ↓
scriptPubKey
        ↓
Transaction output
        ↓
Confirmed UTXO
        ↓
Future spending condition

जब आप बिटकॉइन भेजते हैं, तो वॉलेट किसी वस्तु को एक पते की स्ट्रिंग से दूसरे में नहीं ले जाता है। यह मौजूदा UTXO को लेनदेन इनपुट के रूप में उपभोग करता है और नए आउटपुट बनाता है। गंतव्य पता उन आउटपुट में से एक को बनाने के लिए आवश्यक जानकारी प्रदान करता है।.

यही कारण है कि पते का प्रारूप तकनीकी रूप से मायने रखता है। एक P2PKH पता P2WPKH पते से भिन्न आउटपुट स्क्रिप्ट की ओर ले जाता है। एक Taproot P2TR आउटपुट फिर से अलग होता है। वे आउटपुट सभी खर्च योग्य बिटकॉइन का प्रतिनिधित्व कर सकते हैं, लेकिन जब वे खर्च किए जाते हैं तो उपयोग की जाने वाली शर्तें और क्रमबद्धता समान नहीं होती हैं।.

पता निजी कुंजी नहीं है

निजी कुंजी पते से अलग रहती है। एक वॉलेट खर्च की शर्त द्वारा आवश्यक हस्ताक्षर या गवाह डेटा बनाने के लिए निजी-कुंजी सामग्री का उपयोग करता है। एक प्राप्त करने वाला पता प्रकाशित करने से निजी कुंजी प्रकाशित नहीं होती है।.

विपरीत भी महत्वपूर्ण है: किसी पते को देखना यह साबित नहीं करता है कि कोई विशेष व्यक्ति संबंधित कुंजी को नियंत्रित करता है। ब्लॉकचेन विश्लेषण लेनदेन और आउटपुट का निरीक्षण कर सकता है, लेकिन अकेले पते की स्ट्रिंग पहचान का प्रमाण नहीं है।.

कई प्रारूप क्यों मौजूद हैं

Bitcoin में कई पता प्रारूप हैं क्योंकि लेनदेन प्रणाली पुराने आउटपुट के साथ संगतता बनाए रखते हुए विकसित हुई। नए प्रारूपों ने ब्लॉकचेन पर पुराने आउटपुट को प्रतिस्थापित नहीं किया। इसके बजाय, उन्होंने खर्च की शर्तों को व्यक्त करने के अतिरिक्त तरीके पेश किए।.

Bitcoin मेननेट पर उपयोगकर्ताओं के सामने आने वाले चार प्रारूप हैं:

विरासत P2PKH, आमतौर पर एक पते के साथ प्रदर्शित होता है जो 1.
P2SH, आमतौर पर 3; nested SegWit P2SH का एक महत्वपूर्ण उपयोग है, लेकिन केवल एक ही नहीं है।.
नेटिव SegWit, Bech32 के साथ एन्कोडेड और आमतौर पर bc1q , witness संस्करण 0 के लिए।.
Taproot, Bech32m के साथ एन्कोडेड और bc1p , witness संस्करण 1 P2TR आउटपुट के लिए।.

महत्वपूर्ण परिवर्तन स्ट्रिंग की उपस्थिति नहीं है। यह है कि डिकोड किया गया गंतव्य वॉलेट को नए आउटपुट में क्या रखने के लिए कहता है।.

Bitcoin पता प्रकार तुलना

सामान्य नाम	मुख्यनेट उपसर्ग	एन्कोडिंग	विशिष्ट आउटपुट	उपसर्ग आपको क्या बताता है
लीगेसी	`1`	Base58Check	P2PKH	मुख्यनेट पब्लिक-की-हैश पते के लिए संस्करण-बाइट परिवार
P2SH (नेस्टेड SegWit सहित)	`3`	Base58Check	P2SH; नेस्टेड SegWit एक संभावित रिडीम-स्क्रिप्ट निर्माण है	गंतव्य P2SH है, इसके अंदर सटीक रिडीम स्क्रिप्ट नहीं
नेटिव SegWit	`bc1q`	Bech32	Witness v0, आमतौर पर P2WPKH या P2WSH	मेननेट Bech32 witness-version-0 गंतव्य
Taproot	`bc1p`	Bech32m	P2TR	मेननेट witness-version-1 Taproot गंतव्य

यह तालिका पहचान के लिए उपयोगी है, लेकिन उपसर्ग भविष्य के खर्च व्यवहार का पूर्ण विवरण नहीं है। सबसे स्पष्ट उदाहरण एक 3... पता है: यह P2SH की पहचान करता है, लेकिन P2SH कई रिडीम स्क्रिप्ट्स के लिए प्रतिबद्ध हो सकता है। नेस्टेड SegWit केवल एक संभावना है।.

Legacy P2PKH पते

Legacy pay-to-public-key-hash, या P2PKH, पता प्रारूप है जो प्रारंभिक Bitcoin वॉलेट सॉफ्टवेयर से सबसे अधिक जुड़ा हुआ है। मेननेट पर, ये Base58Check पते आम तौर पर 1.

से शुरू होते हैं। पता एक सार्वजनिक कुंजी के हैश का प्रतिनिधित्व करता है। जब एक वॉलेट उस गंतव्य को भुगतान करता है, तो यह एक P2PKH लॉकिंग स्क्रिप्ट बनाता है जिसके लिए आउटपुट खर्च होने पर एक मान्य हस्ताक्षर और संबंधित सार्वजनिक कुंजी की आवश्यकता होती है।.

OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG

दृश्यमान पता इसलिए स्वयं स्क्रिप्ट नहीं है। वॉलेट Base58Check पते को डिकोड करता है, संस्करण और पेलोड निकालता है, और उपयुक्त scriptPubKey का निर्माण करता है।.

P2PKH आउटपुट मान्य Bitcoin आउटपुट बने रहते हैं। “Legacy” का अर्थ अमान्य या स्वचालित रूप से असुरक्षित नहीं है। अंतर तब प्रासंगिक हो जाता है जब लेनदेन संरचना की तुलना की जाती है: एक पारंपरिक P2PKH आउटपुट खर्च करने से अनलॉकिंग डेटा इनपुट स्क्रिप्ट में रखा जाता है, न कि SegWit विटनेस सीरियलाइज़ेशन का उपयोग करके।.

यह अंतर सामान्य SegWit कुंजी खर्च की तुलना में लेनदेन भार बढ़ा सकता है। इसका मतलब यह नहीं है कि P2PKH भुगतान में स्वचालित रूप से एक विशेष शुल्क होता है। इनपुट गिनती, आउटपुट गिनती, चयनित शुल्क दर और हस्ताक्षरित लेनदेन के बाकी हिस्से अंतिम लागत निर्धारित करते हैं।.

P2SH और नेस्टेड SegWit

Pay-to-script-hash, या P2SH, ने खर्च तर्क का कुछ हिस्सा हैश के पीछे स्थानांतरित कर दिया। मेननेट P2SH पते Base58Check का उपयोग करते हैं और आम तौर पर 3.

से शुरू होते हैं। एक मानक P2SH आउटपुट लॉकिंग स्क्रिप्ट में रिडीम-स्क्रिप्ट हैश रखता है:

OP_HASH160

OP_EQUAL

पूर्ण रिडीम स्क्रिप्ट केवल तभी प्रदान की जाती है जब आउटपुट खर्च किया जाता है। इसने SegWit की शुरुआत के समय एक महत्वपूर्ण संगतता उपकरण बनाया: एक SegWit विटनेस प्रोग्राम को P2SH रिडीम स्क्रिप्ट के अंदर रखा जा सकता था, जिससे एक प्रेषक जो सामान्य P2SH पते समझता था, एक आउटपुट का भुगतान कर सकता था जिसे बाद में SegWit नियमों का उपयोग करके खर्च किया जाएगा।.

एक सामान्य एकल-कुंजी निर्माण को P2SH-P2WPKH कहा जाता है:

P2SH पता
    ↓
redeemScript का हैश
    ↓
redeemScript में एक P2WPKH विटनेस प्रोग्राम होता है
    ↓
हस्ताक्षर और सार्वजनिक कुंजी खर्च होने पर विटनेस डेटा के माध्यम से प्रदान की जाती हैं

एक 3-उपसर्ग SegWit साबित नहीं करता

यह दृश्य पता पहचान की सबसे महत्वपूर्ण सीमाओं में से एक है। 3 से शुरू होने वाला पता आपको बताता है कि गंतव्य मेननेट P2SH पता संस्करण का उपयोग करता है। यह आउटपुट खर्च होने से पहले पूर्ण रिडीम स्क्रिप्ट प्रकट नहीं करता है।.

P2SH SegWit से पहले अस्तित्व में था और अन्य स्क्रिप्ट्स को लपेट सकता है। हर 3... इसलिए “एक SegWit पता” के रूप में संबोधित करना बहुत व्यापक है।.

तकनीकी सीमा: उपसर्ग बाहरी पते के प्रारूप की पहचान करता है। यह P2SH हैश के पीछे छिपे सटीक स्क्रिप्ट को साबित नहीं करता है।.

नेटिव SegWit और bc1q

नेटिव SegWit P2SH संगतता रैपर को हटा देता है और विटनेस प्रोग्राम को सीधे प्रस्तुत करता है। BIP 173 ने नेटिव SegWit पतों के लिए Bech32 एन्कोडिंग पेश की।.

Bitcoin मेननेट पर, मानव-पठनीय भाग है bc. विटनेस संस्करण 0 पते उत्पन्न करता है जो आमतौर पर शुरुआत से पहचाने जाते हैं bc1q.

दो सामान्य विटनेस-संस्करण-0 आउटपुट हैं:

P2WPKH: एक 20-बाइट विटनेस प्रोग्राम जो आमतौर पर एकल-कुंजी वॉलेट भुगतान के लिए उपयोग किया जाता है।.
P2WSH: एक 32-बाइट विटनेस प्रोग्राम जो एक विटनेस स्क्रिप्ट के लिए प्रतिबद्ध है।.

एड्रेस स्वयं वॉलेट को विटनेस संस्करण और प्रोग्राम देता है। विटनेस संस्करण 0 के लिए, सामान्य आउटपुट स्क्रिप्ट के ये रूप हैं:

P2WPKH: OP_0 
P2WSH:  OP_0

आउटपुट सीधे P2SH रैपर के बजाय विटनेस प्रोग्राम शामिल करता है। जब UTXO खर्च किया जाता है, तो विटनेस प्रोग्राम द्वारा आवश्यक हस्ताक्षर या स्क्रिप्ट डेटा पारंपरिक P2PKH-शैली scriptSig के बजाय लेनदेन विटनेस में आपूर्ति की जाती है।.

Bech32 त्रुटि पहचान भी बदलता है

Bech32 केवल एक अलग वर्णमाला नहीं है। इसमें इस एड्रेस परिवार के लिए डिज़ाइन किया गया एक चेकसम शामिल है और मानव-पठनीय नेटवर्क भाग को एन्कोडेड विटनेस डेटा से अलग करता है।.

Bech32 स्ट्रिंग्स में अपरकेस और लोअरकेस अक्षरों को मिश्रित नहीं करना चाहिए। वॉलेट आमतौर पर Bitcoin मेननेट Bech32 पते लोअरकेस में प्रदर्शित करते हैं। पूरी तरह से अपरकेस एन्कोडिंग विनिर्देश के तहत मान्य हो सकती है, लेकिन मिश्रित केस अमान्य है।.

Taproot और bc1p

Taproot ने pay-to-Taproot, या P2TR, आउटपुट पेश किए। P2TR 32-बाइट विटनेस प्रोग्राम के साथ विटनेस संस्करण 1 का उपयोग करता है। Bitcoin मुख्यनेट पर, परिणामी पता शुरू होता है bc1p.

विटनेस संस्करण 1 और बाद के संस्करण मूल Bech32 चेकसम के बजाय Bech32m का उपयोग करते हैं। BIP 350 ने नए विटनेस संस्करणों के लिए मूल Bech32 चेकसम व्यवहार का उपयोग करने में एक कमजोरी की पहचान के बाद यह परिवर्तन पेश किया।.

यह एक व्यावहारिक पहचान नियम देता है:

bc1q... → विटनेस संस्करण 0 → Bech32
bc1p... → विटनेस संस्करण 1 P2TR → Bech32m

संबंधित P2TR लॉकिंग स्क्रिप्ट विटनेस संस्करण 1 और 32-बाइट Taproot आउटपुट कुंजी का उपयोग करती है:

OP_1

एक P2TR आउटपुट उस Taproot आउटपुट कुंजी के लिए प्रतिबद्ध है। इसे बाद में कुंजी पथ के माध्यम से खर्च किया जा सकता है या, यदि एक स्क्रिप्ट ट्री प्रतिबद्ध किया गया था, एक मान्य प्रकट स्क्रिप्ट पथ के माध्यम से।.

पता यह प्रकट नहीं करता कि कौन सा पथ अंततः उपयोग किया जाएगा। देखना bc1p आपको बताता है कि आउटपुट P2TR है। यह आपको यह नहीं बताता कि भविष्य का खर्चकर्ता कुंजी-पथ हस्ताक्षर का उपयोग करेगा या स्क्रिप्ट पथ प्रकट करेगा।.

Bitcoin उपसर्ग वास्तव में आपको क्या बताते हैं

उपसर्ग उपयोगी हैं क्योंकि वे एक इंसान को संभावित पता परिवार और नेटवर्क की त्वरित पहचान करने देते हैं। उन्हें पूर्ण सत्यापन के रूप में नहीं, बल्कि प्रारंभिक जांच के रूप में माना जाना चाहिए।.

उदाहरण शुरुआत	संभावित मुख्यनेट अर्थ	यह साबित नहीं करता
`1...`	P2PKH मुख्यनेट पता	मालिक, शेष राशि या प्राप्तकर्ता पहचान
`3...`	P2SH मुख्यनेट पता	कि रिडीम स्क्रिप्ट नेस्टेड SegWit है
`bc1q...`	मूल विटनेस-संस्करण-0 पता	क्या यह अकेले उपसर्ग से P2WPKH या P2WSH है
`bc1p...`	P2TR विटनेस-संस्करण-1 पता	कौन सा Taproot खर्च पथ बाद में उपयोग किया जाएगा

उपसर्ग उस व्यक्ति को भी प्रमाणित नहीं कर सकता जिसने आपको पता दिया। एक पूरी तरह से एन्कोडेड, चेकसम-मान्य पता अभी भी गलत प्राप्तकर्ता का हो सकता है।.

नेटवर्क पता प्रकार से पहले आता है

Legacy, SegWit या Taproot के बीच चयन करने से पहले, पुष्टि करें कि पता उस Bitcoin नेटवर्क से संबंधित है जिसका आप उपयोग करना चाहते हैं।.

Bech32-परिवार एड्रेस इसे अपने मानव-पठनीय भाग के माध्यम से दृश्यमान बनाते हैं। BIP 173 परिभाषित करता है bc Bitcoin मेननेट के लिए और tb Bitcoin टेस्टनेट पतों के लिए। मानव-पठनीय भाग इसलिए नेटवर्क सत्यापन का हिस्सा है, सजावट नहीं।.

Base58Check एड्रेस परिवार भी मेननेट और टेस्ट नेटवर्क के बीच अलग-अलग संस्करण बाइट्स का उपयोग करते हैं, भले ही अंतर उस उपयोगकर्ता के लिए कम स्पष्ट हो जो केवल स्ट्रिंग को देखता है।.

एक वॉलेट को असमर्थित नेटवर्क/एड्रेस संयोजन को अस्वीकार करना चाहिए, लेकिन अंतिम जिम्मेदारी अभी भी भेजने वाले एप्लिकेशन द्वारा दिखाए गए नेटवर्क की पुष्टि करना है। एड्रेस-प्रारूप पहचान नेटवर्क सत्यापन का विकल्प नहीं है।.

व्यापक लेनदेन संदर्भ—इनपुट, आउटपुट, पुष्टिकरण और Bitcoin आधार परत—के लिए, Bitcoin नेटवर्क संदर्भ.

पता प्रकार और लेनदेन शुल्क

यह सुनना आम है कि एक नया Bitcoin पता “सस्ता” है। यह कथन कुछ तुलनाओं में दिशात्मक रूप से उपयोगी है, लेकिन शुल्क नियम के रूप में उपयोग करने के लिए बहुत सरल है।.

प्राप्तकर्ता द्वारा चुना गया पता आज बनाए गए आउटपुट के प्रकार और क्रमबद्ध आकार को प्रभावित करता है। अधिक महत्वपूर्ण बात, जब वह आउटपुट बाद में खर्च किया जाता है, तो उसकी स्क्रिप्ट प्रकार संबंधित लेनदेन इनपुट की संरचना को प्रभावित करता है।.

SegWit लेनदेन Weight लेखांकन को भी बदलता है क्योंकि witness बाइट्स को गैर-witness बाइट्स से अलग तरीके से भारित किया जाता है। इसलिए एक सामान्य Native SegWit key spend का Weight प्रोफ़ाइल एक तुलनीय Legacy P2PKH spend से भिन्न होता है। यह UTXO खर्च होने पर आभासी आकार को प्रभावित करता है, लेकिन यह अभी भी कुल शुल्क को पहले से तय नहीं करता है।.

समान BTC राशि भविष्य की अलग-अलग लागतों का कारण बन सकती है

दो उपयोगकर्ताओं पर विचार करें जिनमें से प्रत्येक को समान मात्रा में बिटकॉइन प्राप्त होता है। एक को P2PKH आउटपुट प्राप्त होता है और दूसरे को P2WPKH आउटपुट प्राप्त होता है। मूल्य समान है। भविष्य की इनपुट संरचना समान नहीं है।.

जब वे UTXO बाद में खर्च किए जाते हैं, तो उनका अनलॉकिंग डेटा अलग तरीके से क्रमबद्ध किया जाता है। यह लेनदेन Weight और इसलिए आभासी आकार को बदलता है। समान sat/vB दर पर, अलग vSize का मतलब अलग कुल शुल्क है।.

यह एक उदाहरणात्मक तकनीकी परिदृश्य है, न कि उपयोगकर्ता लेनदेन रिकॉर्ड या किसी विशिष्ट वॉलेट के बारे में दावा।.

पता प्रकार अभी भी नहीं अकेले अंतिम शुल्क निर्धारित करता है। कई कुशल SegWit इनपुट वाला लेनदेन एकल Legacy इनपुट वाले लेनदेन से बड़ा हो सकता है। आउटपुट गिनती, हस्ताक्षर, स्क्रिप्ट पथ और चुनी गई शुल्क दर भी मायने रखते हैं।.

Weight, आभासी आकार और sat/vB के बीच पूर्ण संबंध के लिए, पढ़ें Bitcoin लेनदेन शुल्क कैसे काम करते हैं. जब आपको वैचारिक तुलना के बजाय लेनदेन-विशिष्ट अनुमान की आवश्यकता हो, तो उपयोग करें Bitcoin लेनदेन शुल्क कैलकुलेटर.

संगतता एक प्रेषक जांच है

एक मान्य Bitcoin पता भुगतान कार्यप्रवाह के लिए उपयोगी नहीं है यदि भेजने वाला वॉलेट या निकासी सेवा प्रारूप को नहीं समझती है।.

यह अंतर विशेष रूप से Native SegWit और बाद में Taproot को अपनाने के दौरान महत्वपूर्ण था। Bitcoin नेटवर्क आउटपुट प्रकार को पहचान सकता था जबकि पुराने अनुप्रयोगों में उस गंतव्य को बनाने के लिए समर्थन की कमी थी।.

जब कोई सेवा एक bc1q या bc1p पता अस्वीकार करती है, तो पते को मैन्युअल रूप से न बदलें। वर्ण न हटाएं, उपसर्ग न बदलें या इसे किसी मनमानी वेबसाइट के माध्यम से परिवर्तित न करें। एक पता प्रारूप का उपयोग करें जो आपके प्राप्त करने वाले वॉलेट ने वास्तव में उत्पन्न किया है और जिसे प्रेषक स्पष्ट रूप से समर्थन करता है।.

प्रारूपों के बीच भेजना रूपांतरण नहीं है

आपको किसी Legacy पते को भुगतान करने के लिए Legacy वॉलेट या Taproot पते को भुगतान करने के लिए Taproot वॉलेट की आवश्यकता नहीं है, इस अर्थ में कि स्रोत और गंतव्य प्रारूप मेल खाते हों। भेजने वाला लेनदेन उन सभी समर्थित UTXO को खर्च करता है जिन्हें वॉलेट चुनता है और गंतव्य स्क्रिप्ट के लिए एक नया आउटपुट बनाता है।.

प्रासंगिक प्रश्न यह है कि क्या भेजने वाला सॉफ़्टवेयर अनुरोधित गंतव्य आउटपुट को डिकोड और निर्मित कर सकता है।.

एक मान्य पता फिर भी गलत हो सकता है

चेकसम कुछ प्रतिलेखन त्रुटियों को पकड़ते हैं। वे इच्छित प्राप्तकर्ता को प्रमाणित नहीं करते हैं।.

यदि मैलवेयर कॉपी किए गए पते को किसी अन्य मान्य Bitcoin पते से बदल देता है, तो प्रतिस्थापन पूरी तरह से चेकसम सत्यापन पास कर सकता है। तकनीकी प्रारूप मान्य है; गंतव्य गलत है।.

यही कारण है कि “वॉलेट ने पता स्वीकार किया” अंतिम सुरक्षा जांच नहीं है। स्वीकृति आपको बताती है कि सॉफ़्टवेयर ने एक मान्य या समर्थित गंतव्य को पहचान लिया है। यह साबित नहीं करता कि पता कहाँ से आया है।.

भेजने से पहले सत्यापित करें

एक उपयोगी सत्यापन प्रक्रिया प्रारूप सत्यापन को प्राप्तकर्ता सत्यापन से अलग करती है।.

नेटवर्क की पुष्टि करें।. सुनिश्चित करें कि वॉलेट या सेवा इच्छित Bitcoin नेटवर्क पर Bitcoin भेज रही है, न कि किसी अन्य संपत्ति या परीक्षण वातावरण पर।.
पता परिवार पढ़ें।. A 1, 3, bc1q या bc1p उपसर्ग आपको प्रारंभिक प्रारूप संकेत देता है।.
प्रेषक समर्थन की पुष्टि करें।. निकासी सेवा या वॉलेट को गंतव्य प्रारूप को स्पष्ट रूप से स्वीकार करना चाहिए।.
किसी विश्वसनीय चैनल के माध्यम से गंतव्य सत्यापित करें।. जहां व्यावहारिक हो, वहां पूरे पते की तुलना किसी विश्वसनीय डिस्प्ले पर करें, न कि केवल कुछ शुरुआती और अंतिम वर्णों पर निर्भर रहें।.
वॉलेट की अंतिम लेनदेन स्क्रीन की समीक्षा करें।. हस्ताक्षर करने से पहले प्राप्तकर्ता, राशि, नेटवर्क शुल्क और किसी भी परिवर्तन की पुष्टि करें।.
निजी सामग्री की सुरक्षा करें।. प्राप्त-पता सत्यापन के लिए आपको कभी भी किसी वेबसाइट में सीड वाक्यांश या निजी कुंजी दर्ज करने की आवश्यकता नहीं होती है।.

बड़े या परिचालन की दृष्टि से संवेदनशील स्थानांतरण के लिए, संगठन अक्सर स्वतंत्र गंतव्य सत्यापन प्रक्रियाएं जोड़ते हैं। वे प्रक्रियाएं एक परिचालन नियंत्रण हैं, न कि किसी विशिष्ट Bitcoin पता प्रारूप की संपत्ति।.

पता पुन: उपयोग एक अलग मुद्दा है

एक Bitcoin पता प्रोटोकॉल स्तर पर केवल इसलिए समाप्त नहीं होता है क्योंकि इसका एक बार उपयोग किया गया है। यदि संबंधित व्यय शर्त नियंत्रणीय बनी रहती है, तो उसी पते पर भविष्य के भुगतान अभी भी मान्य आउटपुट बना सकते हैं।.

इसका मतलब यह नहीं है कि पता पुन: उपयोग वांछनीय है। प्राप्त पते का पुन: उपयोग करने से लेनदेन को सार्वजनिक blockchain पर जोड़ना आसान हो सकता है और गोपनीयता कम हो सकती है।.

यह गोपनीयता प्रश्न इस बात से अलग है कि पता P2PKH, P2SH, P2WPKH या P2TR है या नहीं। एक आधुनिक पता प्रारूप उसी दृश्यमान गंतव्य के बार-बार उपयोग को निजी नहीं बनाता है।.

पता सत्यापन की सीमाएं

प्रारूप सत्यापन एक संकीर्ण प्रश्न का उत्तर देता है: क्या स्ट्रिंग को प्रासंगिक पता नियमों के तहत अपेक्षित प्रकार के Bitcoin गंतव्य के रूप में डिकोड किया जा सकता है। यह उस व्यक्ति को प्रमाणित नहीं करता है जिसने इसे प्रदान किया है, निजी कुंजी के स्वामित्व को साबित नहीं करता है, वॉलेट की कुल शेष राशि को साबित नहीं करता है, यह गारंटी नहीं देता है कि कोई सेवा प्रारूप का समर्थन करती है, या अंतिम लेनदेन शुल्क निर्धारित नहीं करता है।.

यह आउटपुट निर्माण द्वारा जानबूझकर छिपाई गई जानकारी को भी प्रकट नहीं कर सकता है। एक P2SH पता व्यय से पहले पूर्ण redeem script को उजागर नहीं करता है, और एक P2TR पता आपको पहले से नहीं बताता है कि भविष्य का व्यय key path का उपयोग करेगा या script path को प्रकट करेगा। सफल डिकोडिंग को भुगतान प्रक्रिया में एक जांच के रूप में मानें, न कि यह प्रमाण कि आसपास की हर धारणा सही है।.

प्राप्त प्रारूप चुनना

सबसे सुरक्षित डिफ़ॉल्ट यह है कि आप उस पते का उपयोग करें जो आपके द्वारा वास्तव में नियंत्रित वॉलेट द्वारा उत्पन्न किया गया है, न कि मैन्युअल रूप से पता बनाना या परिवर्तित करना।.

यदि प्राप्त करने वाला वॉलेट एक से अधिक पता प्रकार प्रदान करता है, तो उस प्रकार का उपयोग करें जो वॉलेट की इच्छित स्क्रिप्ट नीति से मेल खाता हो और जिसे प्रेषक डिकोड कर सके। P2WPKH पता उपयुक्त है जब वॉलेट जानबूझकर witness-version-0 key-hash गंतव्य उत्पन्न करता है। P2TR पता उपयुक्त है जब वॉलेट जानबूझकर Taproot गंतव्य उत्पन्न करता है और प्रेषक इसका समर्थन करता है। पुराने P2PKH या P2SH गंतव्य तब भी मान्य रहते हैं जब किसी कार्यप्रवाह को उन प्रारूपों की आवश्यकता होती है।.

केवल इसलिए प्रारूप न चुनें क्योंकि कोई दावा करता है कि यह “सबसे सस्ता” है। आज आपके द्वारा बनाया गया आउटपुट केवल तब इनपुट बनता है जब इसे बाद में खर्च किया जाता है, और उस भविष्य के लेनदेन की अंतिम लागत पूरी लेनदेन संरचना और शुल्क दर पर निर्भर करती है।.

पता प्राप्त करने वाले वॉलेट से आना चाहिए। प्रेषक को इसका समर्थन करना चाहिए। नेटवर्क मेल खाना चाहिए। ये तीन जाँचें अकेले उपसर्ग का पीछा करने से अधिक महत्वपूर्ण हैं।.

Bitcoin पता FAQ

bc1q और bc1p के बीच क्या अंतर है?

bc1q आमतौर पर Bech32 के साथ एन्कोड किए गए Bitcoin मुख्य नेटवर्क witness-version-0 पते की शुरुआत है, जैसे P2WPKH या P2WSH।. bc1p Bech32m के साथ एन्कोड किए गए मुख्य नेटवर्क witness-version-1 P2TR पते की पहचान करता है।.

क्या 3 से शुरू होने वाला हर Bitcoin पता SegWit का उपयोग करता है?

नहीं। एक मुख्य नेटवर्क पता जो 3 एक P2SH पता है। नेस्टेड SegWit P2SH का उपयोग कर सकता है, लेकिन P2SH अन्य रिडीम स्क्रिप्ट के लिए प्रतिबद्ध हो सकता है, इसलिए अकेला उपसर्ग यह साबित नहीं करता कि आउटपुट नेस्टेड SegWit है।.

क्या Bitcoin पते केस-संवेदी हैं?

Base58Check पते केस-संवेदी वर्णमाला का उपयोग करते हैं। Bech32 और Bech32m एन्कोडिंग में ऊपरी और निचले अक्षरों को मिश्रित नहीं करना चाहिए; Bitcoin वॉलेट आमतौर पर उन्हें लोअरकेस में प्रदर्शित करते हैं। किसी पते का केस मैन्युअल रूप से न बदलें।.

क्या मैं एक पते के प्रकार से दूसरे में Bitcoin भेज सकता हूँ?

हाँ, जब भेजने वाला वॉलेट गंतव्य प्रारूप का समर्थन करता है। एक लेनदेन एक समर्थित इनपुट प्रकार खर्च कर सकता है और एक अलग समर्थित आउटपुट प्रकार बना सकता है। स्रोत और गंतव्य उपसर्गों का मिलान होना आवश्यक नहीं है।.

क्या Bitcoin पता समाप्त हो जाता है?

कोई प्रोटोकॉल नियम सामान्य Bitcoin पते को निर्धारित तिथि या एक भुगतान के बाद समाप्त नहीं करता। वॉलेट अक्सर नए प्राप्त पते उत्पन्न करते हैं क्योंकि पते का पुन: उपयोग गोपनीयता कम कर सकता है, न कि इसलिए कि पहले उत्पन्न पते स्वतः अमान्य हो जाते हैं।.

मुझे कौन सा Bitcoin पता प्रकार उपयोग करना चाहिए?

प्राप्त करने वाले वॉलेट द्वारा उत्पन्न पते का उपयोग करें जिस Bitcoin नेटवर्क और स्क्रिप्ट प्रकार के लिए आप उपयोग करना चाहते हैं, फिर पुष्टि करें कि भेजने वाला उस प्रारूप का समर्थन करता है। नेटिव SegWit आधुनिक भुगतानों के लिए सामान्य है, जबकि Taproot उपयुक्त है जब दोनों पक्ष P2TR का समर्थन करते हैं। किसी पते के प्रारूप को मैन्युअल रूप से दूसरे में परिवर्तित न करें।.

तकनीकी स्रोत

उपरोक्त पता-प्रारूप विवरण Bitcoin सुधार प्रस्तावों और Bitcoin Core दस्तावेज़ीकरण पर आधारित हैं। ये संदर्भ पता एन्कोडिंग, विटनेस प्रोग्राम और स्क्रिप्ट व्यवहार को परिभाषित करते हैं; वे किसी विशिष्ट प्राप्त पते की पहचान या सुरक्षा साबित नहीं करते। BitcoinToolkit का व्यापक स्रोत दृष्टिकोण डेटा स्रोत page.

BIP 13: pay-to-script-hash के लिए पता प्रारूप — Base58Check P2SH पता प्रारूप निर्दिष्ट करता है।.
BIP 16: स्क्रिप्ट हैश को भुगतान करें — P2SH खर्च मॉडल और रिडीम-स्क्रिप्ट मूल्यांकन को परिभाषित करता है।.
BIP 49: P2WPKH-nested-in-P2SH के लिए व्युत्पत्ति योजना — इस गाइड में चर्चित सामान्य एकल-कुंजी नेस्टेड-SegWit निर्माण का दस्तावेजीकरण करता है।.
BIP 141: पृथक गवाह — विटनेस प्रोग्राम, लेनदेन Weight और SegWit आउटपुट शब्दार्थ को परिभाषित करता है।.
BIP 173: मूल v0-16 विटनेस आउटपुट के लिए Base32 पता प्रारूप — Bech32 नेटिव SegWit पता एन्कोडिंग पेश किया।.
BIP 350: v1+ विटनेस पतों के लिए Bech32m प्रारूप — Bech32m और नए witness संस्करणों के लिए checksum नियम को परिभाषित करता है।.
BIP 341: Taproot — Taproot आउटपुट और खर्च नियमों को परिभाषित करता है, जिसमें P2TR witness संस्करण 1 शामिल है।.
Bitcoin Core आउटपुट डिस्क्रिप्टर — सामान्य Bitcoin आउटपुट स्क्रिप्ट और key अभिव्यक्तियों के संरचित विवरणों का दस्तावेजीकरण करता है।.

स्रोत

कोई त्रुटि मिली? किसी सामग्री समस्या की रिपोर्ट करें या हमारा पढ़ें सुधार नीति.