पुष्टि

एलिस अपने दोस्त को 20 000 sat भेजती है। sat बिटकॉइन की सबसे छोटी इकाई है। उसके वॉलेट में भेजा गया दिखता है और दोस्त भी आने वाला भुगतान देखता है, लेकिन पुष्टि शून्य है। इसमें विरोधाभास नहीं: जानकारी नोडों तक, यानी बिटकॉइन जाँचने वाले कंप्यूटरों तक पहुँची है, पर अभी ब्लॉक में नहीं आई। Mempool किसी नोड का अपुष्ट लेनदेन रखने का स्थानीय संग्रह है, पूरे नेटवर्क की एक साझा कतार नहीं। भुगतान स्वीकृत ब्लॉक में आते ही पहली पुष्टि मिलती है। अगला ब्लॉक दूसरी और उसके बाद का तीसरी देता है। एलिस को फिर भेजने की ज़रूरत नहीं। लेनदेन फैलाना उसकी पुष्टि नहीं है और पहचानकर्ता txid भी पुष्टि की गारंटी नहीं देता। अपुष्ट लेनदेन बदला जा सकता है, जैसे शुल्क बढ़ाने के लिए Replace-by-Fee (RBF) से। बिना पुष्टि भुगतान स्वीकार करना zero-conf कहलाता है। इसमें जोखिम है कि उन्हीं पैसों का कोई दूसरा खर्च पहले पुष्ट हो जाए। [4] [8] [11]

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

बिटकॉइन ब्लॉकों के बीच औसतन दस मिनट का लक्ष्य रखता है, कोई समय-सारणी नहीं। अगला ब्लॉक कुछ सेकंड में या बहुत बाद में आ सकता है। एक घंटा बीतना अपने आप छह पुष्टियाँ नहीं बनाता। ऊँची शुल्क दर माइनर द्वारा आपका लेनदेन चुनने की संभावना बढ़ा सकती है, लेकिन ब्लॉक जल्दी नहीं बनाती। कुछ वॉलेट RBF देते हैं, जिसमें अपुष्ट लेनदेन अधिक शुल्क वाले से बदला जाता है, या CPFP (Child Pays for Parent): उस पर निर्भर अगला लेनदेन इतना शुल्क जोड़ता है कि दोनों को साथ शामिल करना माइनर के लिए लाभकारी हो। उपलब्धता वॉलेट और लेनदेन पर निर्भर है। कम शुल्क लंबा इंतज़ार या नोड के Mempool से हटाए जाने का कारण हो सकता है। इसलिए वॉलेट का समय अनुमान है, वादा किया हुआ समय नहीं। [3] [4]

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

भुगतान को ऐसा रिकॉर्ड मानें जिसके ऊपर इतिहास के नए पन्ने जुड़ते जाते हैं। हमलावर के लिए एक पुराना पन्ना बदलना काफी नहीं: उसे पर्याप्त संचित गणनात्मक काम वाला दूसरा मान्य क्रम भी बनाना होगा। सामान्य धारणाओं में अतिरिक्त पुष्टियाँ इसे कठिन करती हैं। परिणाम हमलावर की गणना क्षमता और नेटवर्क की स्थिति पर भी निर्भर है। अक्सर बताई जाने वाली छह पुष्टियाँ ऐतिहासिक मार्गदर्शन हैं, सहमति का नियम या पूरी सुरक्षा की जादुई सीमा नहीं। सभी परिस्थितियों के लिए इतिहास बदलने की एक तय संभावना देना सही नहीं होगा। अधिक पुष्टियाँ गलत पते या ठग को किए भुगतान को भी ठीक नहीं करतीं। [1] [13]

दो माइनर लगभग एक साथ ब्लॉक खोजें तो बिना हमले के भी छोटा विभाजन हो सकता है। नोड का दूसरी जीतने वाली शाखा पर जाना पुनर्गठन कहलाता है। लेनदेन का आउटपुट रकम और खर्च की शर्तें दर्ज करता है; अगले लेनदेन का इनपुट उसका संदर्भ देकर उसे खर्च करता है। खर्च न हुआ आउटपुट UTXO कहलाता है। यदि दूसरी मान्य शाखा अधिक संचित गणनात्मक काम, यानी chainwork, जुटा ले, तो नोड पुरानी चेन के आखिरी ब्लॉक अलग करके जीतने वाली शाखा जोड़ देता है। अलग किए गए ब्लॉक का लेनदेन, यदि अब भी मान्य है, तो Mempool में लौट सकता है या किसी दूसरी ऊँचाई पर पुष्ट हो सकता है। वह विरोधी लेनदेन भी बन सकता है, यदि नई शाखा ने उसी आउटपुट को खर्च कर दिया हो जिसका उसका इनपुट संदर्भ देता है। Bitcoin Core में confirmations की ऋणात्मक संख्या वॉलेट द्वारा टकराव की गहराई बताने का तरीका है। इसका मतलब सहमति के नियमों में ब्लॉकों की संख्या ऋणात्मक होना नहीं है। [5] [7]

ब्लॉक की ऊँचाई क्रम में उसका स्थान है, जिसकी गिनती शून्य नंबर के शुरुआती ब्लॉक से होती है। यदि लेनदेन वाला ब्लॉक h ऊँचाई पर है और नोड की सक्रिय चेन का आखिरी ब्लॉक H ऊँचाई पर है, तो पुष्टियों की संख्या H − h + 1 है। इस तरह लेनदेन को शामिल करने वाला ब्लॉक स्वयं पहली पुष्टि गिना जाता है। परिणाम उस नोड के सर्वोत्तम सत्यापित ब्लॉक पर निर्भर करता है, इसलिए नए ब्लॉक आने के दौरान नोडों के बीच थोड़े समय के लिए अंतर हो सकता है। यह संख्या लेनदेन का हिस्सा नहीं है, केवल समय बीतने से नहीं बढ़ती और टाइमस्टैम्प से भरोसेमंद ढंग से नहीं निकाली जा सकती। Bitcoin Core संबंधित वॉलेट या UTXO की जानकारी में मौजूद स्थिति के अनुसार blockhash, blockheight और confirmations जैसे डेटा लौटाता है। [3] [5] [6]

SPV का मतलब सरल भुगतान सत्यापन है, जबकि RPC नोड से पूछने का प्रोग्रामिंग इंटरफ़ेस है। दो ऐप एक ही संख्या दिखाएँ, तब भी जाँच के तरीकों का अंतर महत्वपूर्ण है। पूर्ण नोड चेन को सत्यापित करता है और अपनी सत्यापित चेन के मौजूदा आखिरी ब्लॉक के आधार पर उत्तर देता है। SPV क्लाइंट ब्लॉक हेडर में Proof of Work और लेनदेन शामिल होने का Merkle प्रमाण जाँचता है, लेकिन सहमति के सभी नियम स्वयं सत्यापित नहीं करता। Merkle प्रमाण डेटा के कुछ क्रिप्टोग्राफ़िक फ़िंगरप्रिंट की मदद से दिखाता है कि लेनदेन ब्लॉक में शामिल है। इसके लिए उस ब्लॉक के सभी लेनदेन डाउनलोड नहीं करने पड़ते। उपयोगकर्ता की ओर से रकम रखने वाली सेवा भुगतान खाते में जोड़ने और जोखिम सँभालने के अपने नियम भी लागू करती है। पूर्ण नोड का RPC परिणाम भी किसी एक समय की स्थिति दिखाता है, जिसे पुनर्गठन बदल सकता है। इसलिए पुष्टियों की संख्या के साथ यह भी मायने रखता है कि उपयोगकर्ता किसके चेन संबंधी नज़रिए, सत्यापन और रकम की देखभाल पर भरोसा कर रहा है। [1] [2] [8]

Coinbase Transaction ब्लॉक का खास पहला लेनदेन है जो माइनर का इनाम देता है; इसका Coinbase एक्सचेंज से संबंध नहीं। समय-लॉक तय करता है कि पैसे कब खर्च हो सकते हैं। BIP तकनीकी प्रस्ताव या मानक दस्तावेज़ है। पुष्टि से प्रोटोकॉल की कुछ प्रतीक्षा अवधियाँ भी शुरू होती हैं। coinbase लेनदेन का आउटपुट COINBASE_MATURITY = 100 नियम के अधीन है: उसे सबसे पहले उस ब्लॉक में खर्च किया जा सकता है जिसकी ऊँचाई उस coinbase लेनदेन वाले ब्लॉक से 100 अधिक हो। यह ब्लॉक इनाम खर्च करने से पहले की अनिवार्य प्रतीक्षा है, सामान्य भुगतान पाने वाले का चुनाव नहीं। BIP68 के सापेक्ष समय-लॉक खर्च किए जाने वाले आउटपुट की पुष्टि से जुड़े होते हैं और ब्लॉक या समय संबंधी नियमों के अनुसार उसकी उम्र जाँचते हैं। स्क्रिप्ट एक छोटा प्रोग्राम है जो आउटपुट खर्च करने की शर्तें तय करता है। BIP112 का CHECKSEQUENCEVERIFY (CSV) निर्देश इस सापेक्ष शर्त को स्क्रिप्ट में लागू करवाता है। अपुष्ट आउटपुट खर्च करने वाला लेनदेन उसे बनाने वाले लेनदेन पर अब भी निर्भर होता है। आगे का लेनदेन पुष्ट हो सके, इसके लिए उसके पूर्ववर्ती लेनदेन उसी या किसी पुराने ब्लॉक में शामिल होने चाहिए। [9] [10]

Lightning Network बिटकॉइन लेनदेन से वित्तपोषित चैनलों द्वारा भुगतान कराता है। BOLT उसके तकनीकी विनिर्देशों का नाम है। यहाँ चैनल खोलने की बात है, उसके भीतर हर भुगतान के लिए ब्लॉक का इंतज़ार करने की नहीं। BOLT 2, Lightning चैनल स्वीकार करने वाले पक्ष को minimum_depth फ़ील्ड में यह तय करने देता है कि channel_ready संदेश भेजने से पहले फंडिंग लेनदेन को कितनी पुष्टियाँ मिलनी चाहिए। इस आवश्यकता में फंडिंग के दोहरे खर्च का जोखिम ध्यान में रखा जाता है। बिना पुष्टि खोला गया चैनल, यानी zero-conf channel, minimum_depth को शून्य रखता है और जानबूझकर फंड देने वाले पर भरोसे तथा प्रोटोकॉल की सीमाओं पर निर्भर होता है। इससे तत्काल अपरिवर्तनीय निपटान नहीं मिल जाता। यदि फंडिंग लेनदेन स्वयं coinbase लेनदेन है, तो BOLT 2 चैनल खोलने की पहल न करने वाले पक्ष को कम-से-कम 100 ब्लॉक प्रतीक्षा करने को कहता है। संचालक को उस खास फंडिंग आउटपुट, यानी funding outpoint, सक्रिय चेन में उसकी गहराई और पुनर्गठन पर नज़र रखनी चाहिए। केवल txid नेटवर्क पर भेज देने का मतलब चैनल खुल जाना नहीं है। [12] [14]