Finality का अर्थ निपटान की अंतिमता है: पूरा हो चुका हस्तांतरण कायम रहेगा, इस पर कितना भरोसा किया जा सकता है। Bitcoin संभाव्यता पर आधारित आश्वासन देता है, जो आगे जुड़ने वाले वैध काम से मजबूत होता है। पुष्टियों की कोई सार्वभौमिक संख्या अपने आप शाखा बदलने की संभावना नहीं मिटाती और न पूरे समझौते की कानूनी पूर्ति तय करती है।
शुरू में पॉल केवल यह देखता है कि उसके वॉलेट को लेनदेन का पता चल गया है। यह लेनदेन के ब्लॉक में शामिल होने के समान नहीं है। ब्लॉक बनने और उसके बाद नए ब्लॉक जुड़ने पर उस इतिहास को बदलने के लिए अधिक काम से आगे निकलना पड़ता है। व्यावहारिक Finality इसी तरह मजबूत होती है। संभावित हमलावर के संसाधन और नेटवर्क की स्थिति भी मायने रखते हैं। प्रोटोकॉल अपरिवर्तनीयता का गणितीय प्रमाणपत्र नहीं देता; प्राप्तकर्ता को तय करना होता है कि किसी खास भुगतान को स्वीकार करने के आधार कितने मजबूत हैं। [1] [2]
Full Node Bitcoin के नियमों को स्वतंत्र रूप से जाँचता है। वह किसी इतिहास को केवल लंबा होने के कारण स्वीकार नहीं करता। पहले उसकी वैधता जाँची जाती है, फिर वैध शाखाओं में से सबसे अधिक संचित काम वाली शाखा चुनी जाती है। यह ब्लॉकों से साबित होने वाला काम है, लोगों की संख्या या उनके सिक्कों के आधार पर मतदान नहीं। अधिक काम किसी अवैध लेनदेन को वैध नहीं बनाता। पॉल के लिए दोनों बातें जरूरी हैं: भुगतान नियमों के अनुरूप हो और वर्तमान वैध इतिहास में उसकी गहराई मालूम हो। [1]
हमारे उदाहरण में पॉल का लेनदेन ऊँचाई 800000 वाले ब्लॉक में है और उसी शाखा का मौजूदा सिरा ऊँचाई 800005 पर है। ऊँचाई ब्लॉक की स्थिति बताती है, समय नहीं। गणना है 800005 − 800000 + 1 = 6 पुष्टियाँ; इसमें लेनदेन वाला ब्लॉक स्वयं भी गिना जाता है। केवल बाद में आए ब्लॉक नहीं गिने जाते। भुगतान अगर सिर्फ mempool में है, यानी उस नोड के अपुष्ट लेनदेन के संग्रह में, तो उसकी 0 पुष्टियाँ हैं। केवल समय बीतने से यह संख्या नहीं बढ़ती। [2] [3]
नेटवर्क कुछ समय के लिए प्रतिस्पर्धी ब्लॉकों को जान सकता है और फिर अधिक काम वाली दूसरी वैध शाखा पर आगे बढ़ सकता है। सक्रिय इतिहास में इस बदलाव को पुनर्गठन कहते हैं। Bitcoin Core 28.0 के दस्तावेज़ में ब्लॉक हेडर की क्वेरी getblockheader, ब्लॉक सक्रिय चेन से बाहर होने पर confirmations = -1 लौटाती है। यह ब्लॉक की स्थिति है, उसके सभी भुगतानों के खो जाने का प्रमाण नहीं। पॉल का लेनदेन नई शाखा में भी हो सकता है, बिना पुष्टि के प्रतीक्षा कर सकता है या दूसरे लेनदेन से टकरा सकता है। उसकी वास्तविक स्थिति दोबारा जाँचनी होगी। [1] [3]
डेवलपर गाइड मूल्यवान भुगतानों के लिए 6 पुष्टियों को प्रचलित सीमा बताती है, साथ ही जोखिम के आकलन की जरूरत भी समझाती है। यह प्राप्तकर्ता का स्वीकृति नियम है, Bitcoin की सहमति के नियम बदलने का बिंदु नहीं। पॉल को साइकिल का मूल्य, संभावित नुकसान और अपनी जाँच की विश्वसनीयता देखनी चाहिए; संख्या उसके लिए फैसला नहीं करती। लगभग एक घंटे का औसत भी यह नहीं कहता कि छह ब्लॉक हमेशा एक घंटे में आ जाएँगे। माइनिंग की निश्चित समय-सारणी नहीं है और पुरानी सामान्य सलाह हर परिस्थिति की गारंटी नहीं देती। [2]
पॉल के पास पुष्ट BTC हो सकते हैं और फिर भी साइकिल सौंपने या उसकी हालत को लेकर विवाद रह सकता है। PFMI, यानी वित्तीय बाज़ार ढाँचों के अंतरराष्ट्रीय सिद्धांत, अंतिम निपटान का स्पष्ट समय और वह सीमा तय करने को कहते हैं जिसके बाद सहभागी अपना निर्देश वापस नहीं ले सकता। यह Bitcoin के ब्लॉक गिनने से अलग ढाँचा है। पुष्टियाँ अकेले अनुबंध का कानूनी प्रभाव, बैंक भुगतान की अंतिमता या बेची गई वस्तु का स्वामित्व हस्तांतरण तय नहीं करतीं। भुगतान की जाँच जरूरी है, लेकिन वह सौदे की बाकी शर्तों की जगह नहीं लेती। [4]
अगर पॉल और खरीदार पैसे लौटाने पर सहमत हों, तो सामान्य रिफंड मूल भुगतान के प्राप्तकर्ता द्वारा भेजे गए नए लेनदेन से होता है। पहला हस्तांतरण इतिहास में बना रहता है। Bitcoin में कोई केंद्रीय सहायता केंद्र नहीं है जो अनुरोध पर एक बटन से पुष्ट भुगतान रद्द कर दे। पुनर्गठन नेटवर्क का सक्रिय इतिहास बदलता है; वह गलतियाँ सुधारने की ग्राहक सेवा नहीं है। इसलिए भेजने से पहले प्राप्तकर्ता और रकम जाँचनी चाहिए। अधिक पुष्टियों की प्रतीक्षा करने से गलत दर्ज किया गया भुगतान ठीक नहीं होगा। [5]
भुगतान ऐप चलाने वाले का काम भुगतान स्वीकार करते ही समाप्त नहीं होता। उसे लेनदेन, उसका ब्लॉक और जाँच का स्रोत दर्ज करना चाहिए, और पहचानना चाहिए कि नोड नेटवर्क से पीछे तो नहीं रह गया। confirmations का मान क्वेरी के समय की स्थिति है, स्थायी प्रमाणपत्र नहीं। संख्या घटने या टकराव सामने आने पर ऐप को पहले से तय प्रक्रिया अपनाकर सक्रिय शाखा फिर जाँचनी चाहिए। पुराना स्क्रीनशॉट नया सबूत नहीं है। पॉल के लिए सीधी बात है: फैसला भुगतान की वर्तमान स्थिति पर करें, केवल उस पर नहीं जो वॉलेट ने कभी दिखाया था। [2] [3]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें पुष्टि, Proof of Work, Settlement risk, Delivery versus payment. इस प्रविष्टि का उल्लेख यहाँ भी है Byzantine Generals Problem, Delivery versus payment.