दोहरा खर्च नए बिटकॉइन बनाना नहीं है। भेजने वाला दो लेनदेन बनाता है जो पहले मिली एक ही रकम के कम से कम एक हिस्से को खर्च करना चाहते हैं। दोनों नेटवर्क में फैल सकते हैं, लेकिन एक ही इतिहास में दोनों मान्य नहीं हो सकते। बिना पुष्टि भुगतान, यानी zero-conf, स्वीकार करने का मतलब यह स्पष्ट होने से पहले कदम उठाना है कि कौन-सा विकल्प टिकेगा।
मान लें कि टॉम के पास पहले मिला 100 000 sat का एक आउटपुट है। sat बिटकॉइन की सबसे छोटी इकाई है और अब तक खर्च न हुए आउटपुट को UTXO कहते हैं। वह ऐलिस को 99 000 sat देने और 1 000 sat शुल्क रखने वाला भुगतान तैयार करता है। लेकिन वह एक दूसरा लेनदेन भी हस्ताक्षरित कर सकता है जो उसी UTXO को खर्च करके रकम कहीं और भेजता हो। दोनों धन के एक ही स्रोत का इस्तेमाल करते हैं, इसलिए टकराते हैं। यह फ़ाइल की कॉपी बनाने जैसा नहीं है: नियम जाँचने वाला कंप्यूटर, यानी Bitcoin नोड, एक मान्य चेन में एक ही आउटपुट दो बार खर्च नहीं होने देता। धोखा तब सफल होगा जब ऐलिस पहले भुगतान पर सामान सौंप दे, लेकिन स्वीकार किए गए इतिहास में दूसरा भुगतान रह जाए। नए सिक्के नहीं बने; ऐलिस ने हारने वाले विकल्प पर भरोसा किया। तकनीकी रूप से हर इनपुट पुराने लेनदेन की पहचान txid और आउटपुट नंबर से किसी पिछले आउटपुट को बताता है। इस जोड़ी को outpoint कहते हैं। [1] [3] [7]
ऐलिस को कुछ ही सेकंड में आता हुआ भुगतान दिख सकता है। इसका मतलब अभी यह नहीं कि वह ब्लॉक में दर्ज हो चुका है। Mempool किसी नोड के अपुष्ट लेनदेन का स्थानीय संग्रह है। पूरे Bitcoin के लिए न तो एक वैश्विक Mempool है, न सबको एक जैसा मिलने वाला क्रम। दूसरे नोड को विरोधी विकल्प पहले मिला हो सकता है या उसने ऐलिस वाला विकल्प देखा ही न हो। first-seen नीति लेनदेन आगे भेजते समय पहले मिले विकल्प को प्राथमिकता देती है। यह वादा नहीं कि माइनर उसी को ब्लॉक में रखेगा। इसलिए वॉलेट का स्क्रीनशॉट या अकेला txid निपटान का प्रमाण नहीं है। मायने यह रखता है कि भरोसेमंद तरीके से जाँची गई चेन में उस खास भुगतान की स्थिति क्या है। [2] [5]
ऐलिस खुद भी एक ईमानदार भुगतान भेज रही हो सकती है जो लंबे समय से प्रतीक्षा कर रहा हो। Replace-by-Fee (RBF) अपुष्ट लेनदेन को दूसरे से बदलने देता है, आम तौर पर अधिक शुल्क वाले लेनदेन से। txid बदलने पर भी प्राप्तकर्ता को उतनी ही रकम मिल सकती है। नया विकल्प कम से कम कुछ पुराने धन का इस्तेमाल करता है, इसलिए तकनीकी रूप से मूल लेनदेन से टकराता है, जबकि किसी का प्राप्तकर्ता को ठगने का इरादा नहीं होता। नया भुगतान क्या करता है और परिस्थितियाँ क्या हैं, यह महत्वपूर्ण है; सिर्फ RBF का निशान नहीं। हालाँकि, यही तरीका पैसा किसी दूसरी जगह भी भेज सकता है। Bitcoin Core में संस्करण 28 से Full-RBF डिफ़ॉल्ट नीति है; इसमें मूल लेनदेन का बदलने योग्य होने का संकेत देना जरूरी नहीं है। नया लेनदेन फिर भी नोड के शुल्क और दुरुपयोग रोकने वाले नियमों पर खरा उतरना चाहिए। इसलिए RBF संकेत का न होना भी अपुष्ट भुगतान को अपरिवर्तनीय नहीं बनाता। [5] [6] [15]
जब भुगतान नोड द्वारा स्वीकार किए गए मान्य ब्लॉक में आता है, तो उसे पुष्टि मिलती है। उसके बाद आने वाले ब्लॉक आम तौर पर उस इतिहास को बदलना कठिन करते हैं और सफल धोखाधड़ी का जोखिम घटाते हैं। लेकिन हर स्थिति के लिए एक सुरक्षित संख्या नहीं है। कॉफ़ी के पैसे खोना, कार सौंपना और एक्सचेंज से बड़ी निकासी मंजूर करना अलग-अलग जोखिम हैं। अक्सर बताई जाने वाली छह पुष्टियाँ एक प्रथा हैं, Bitcoin का नियम नहीं। रकम, नुकसान की भरपाई की गुंजाइश, चेन का असामान्य व्यवहार और सूचना के स्रोत की गुणवत्ता देखनी चाहिए। नोड को अलग-थलग करने वाला Eclipse Attack उसे नेटवर्क की गलत तस्वीर दिखा सकता है। इसलिए प्रतीक्षा जाँच के साथ होनी चाहिए, जाँच की जगह नहीं। [2] [10]
नोड का दूसरी मान्य शाखा पर जाना पुनर्गठन कहलाता है। Proof of Work ब्लॉक बनाने के लिए जरूरी काम का प्रमाण देता है; शाखा के संचित काम को chainwork कहते हैं। भुगतान पुष्ट हो जाने के बाद Mempool में लेनदेन बदलकर उसे रद्द नहीं किया जा सकता। एक दूसरी मान्य शाखा को मूल भुगतान छोड़ना, दूसरा खर्च शामिल करना और प्राप्तकर्ता की सक्रिय चेन से अधिक संचित काम, यानी chainwork, जुटाना पड़ता है। चेन का पुनर्गठन धोखाधड़ी के बिना भी हो सकता है, जैसे लगभग एक साथ ब्लॉक माइन होने पर या सॉफ़्टवेयर अथवा नेटवर्क की गड़बड़ी से। पीड़ित के खिलाफ दोहरा खर्च तभी सफल कहा जाएगा जब विरोधी लेनदेन की जीत के कारण हमलावर को मूल्य मिले। वॉलेट के हार चुके लेनदेन के लिए Bitcoin Core, confirmations फ़ील्ड में पुष्टियों की ऋणात्मक संख्या और walletconflicts फ़ील्ड में संबंधित टकराव दिखा सकता है। [4] [7] [8]
Hashrate माइनिंग के दौरान गणनाओं की गति है। बड़ा हिस्सा इतिहास की दौड़ में मदद करता है, लेकिन दूसरे नियमों से छूट नहीं देता। गुप्त रूप से माइन की गई शाखा ईमानदारी से बनी चेन को पकड़ पाएगी या नहीं, इसकी संभावना नेटवर्क की कुल गणनात्मक शक्ति में हमलावर के हिस्से और पुष्टियों की संख्या जैसे कारकों पर निर्भर करती है। उसे कितनी रकम मिल सकती है, इसका असर मुख्य रूप से इस पर पड़ता है कि हमला उसके लिए फ़ायदेमंद होगा या नहीं। हिस्सा 50 % से कम होने का मतलब शून्य संभावना नहीं है; लगातार बहुमत बनाए रखने से दूसरी शाखा की बराबरी करने की संभावना बहुत बढ़ जाती है। लेकिन बहुमत होने पर भी माइनर हस्ताक्षर जाली नहीं बना सकते, दूसरे लोगों के UTXO खर्च नहीं कर सकते, नए सिक्कों के निर्गम के नियम नहीं तोड़ सकते और पूर्ण नोडों को अमान्य ब्लॉक स्वीकार करने के लिए मजबूर नहीं कर सकते। हमले का आकलन करते समय गणनात्मक शक्ति, ऊर्जा और ईमानदार माइनिंग छोड़ने से खोए इनाम को ध्यान में रखना चाहिए। उपलब्ध पूँजी, असफलता का जोखिम और पकड़े जाने की संभावना भी मायने रखते हैं। लाभ में वित्तीय बाज़ारों में ली गई पोज़िशनों से कमाई भी हो सकती है, इसलिए केवल माइनिंग मशीनों का किराया देखकर अनुमान लगाना पर्याप्त नहीं है। [1] [10] [12]
यहाँ race का अर्थ समय की दौड़ है: प्राप्तकर्ता और माइनर अलग-अलग लेनदेन पहले देख सकते हैं। race attack एक ऐसी दौड़ है जिसमें भुगतानकर्ता एक लेनदेन व्यापारी को और उससे टकराने वाला लेनदेन माइनरों या दूसरे नोडों को भेजता है। उसकी कोशिश होती है कि ब्लॉक किसी एक विकल्प को चुनने से पहले व्यापारी माल इस तरह सौंप दे कि उसे वापस न लिया जा सके। नतीजा लेनदेन के प्रसार, व्यापारी को दिखाई देने वाले नेटवर्क, माइनरों के चुनाव और माल सौंपने के समय पर निर्भर करता है। कई स्वतंत्र नोडों से नेटवर्क पर नज़र रखने से टकराव बेहतर पकड़ में आते हैं, लेकिन अपरिवर्तनीय निपटान की गारंटी नहीं मिलती। race, Finney और Vector76 नाम हमले की परिस्थितियाँ बताते हैं; वे न तो लेनदेन के डेटा फ़ील्ड हैं और न अलग सहमति नियम। [2] [11]
Finney attack ऐसी परिस्थिति का नाम है जिसमें हमलावर के पास माइनिंग की क्षमता भी होती है। यह वॉलेट में सामान्य रूप से शुल्क बढ़ाना नहीं है। Finney attack में माइनिंग करने में सक्षम हमलावर पहले निजी तौर पर एक ब्लॉक माइन करता है, जिसमें रकम वापस उसे देने वाला विरोधी लेनदेन होता है। फिर वह उसी UTXO से ऐसे व्यापारी को भुगतान करता है जो बिना पुष्टि भुगतान स्वीकार करता है, और माल मिलने के बाद छिपा हुआ ब्लॉक प्रकाशित कर देता है। योजना तभी सफल होती है जब ब्लॉक अब भी इस्तेमाल करने योग्य हो और किसी ईमानदारी से माइन किए गए प्रतिस्पर्धी ब्लॉक के उसकी तैयारी बिगाड़ने से पहले नेटवर्क उसे स्वीकार कर ले। इस तरह हमलावर ब्लॉक इनाम और माइनिंग की लागत, दोनों दाँव पर लगाता है। व्यापारी का लेनदेन सत्यापित ब्लॉक में शामिल होने तक प्रतीक्षा करना इस पारंपरिक तरीके को रोकता है, लेकिन बाद में चेन के पुनर्गठन का जोखिम खत्म नहीं करता। [1] [11]
RPC नोड का प्रोग्रामिंग इंटरफ़ेस है। आगे दिए नाम भुगतान सिस्टम बनाने वालों के लिए कमांड और फ़ील्ड हैं, कोई अलग तरह की पुष्टि नहीं। व्यापारी का सिस्टम अपने पूर्ण नोड पर Mempool में विरोधी खर्चों को देख सकता है, gettxspendingprevout कॉल कर सकता है, walletconflicts फ़ील्ड पढ़ सकता है, सक्रिय चेन के सबसे नए ब्लॉक की तुलना कर सकता है और पुष्टियाँ खोने पर चेतावनी दे सकता है। अधिक जुड़े हुए या स्वतंत्र नोड अनदेखे हिस्से कम करते हैं, लेकिन कोई टकराव न मिलना सुरक्षा का कमजोर प्रमाण है: हमलावर विरोधी लेनदेन रोककर रख सकता है या उसे दूसरे रास्ते से भेज सकता है। ब्लॉक एक्सप्लोरर अपने नोड को दिख रही स्थिति बताता है और उसमें देरी हो सकती है। टकराव पकड़ में आने पर माल सौंपना रोका जा सकता है। लेकिन इससे माइनरों को किसी खास लेनदेन को चुनने का आदेश नहीं दिया जा सकता, न ही अपुष्ट भुगतान को पुष्ट भुगतान के बराबर बनाया जा सकता है। [8] [9] [11]
वास्तव में आए भुगतान का गंतव्य, रकम और पुष्टियाँ जाँचें। भेजने वाले की रसीद इसका विकल्प नहीं है। अपना पूर्ण नोड नियमों को सीधे जाँचने देता है। किसी दूसरी सेवा का उपयोग करते हुए समझें कि सूचना और, जहाँ लागू हो, धन की अभिरक्षा के लिए किस पर निर्भर हैं। व्यापारी के सिस्टम को ऑर्डर खास आउटपुट से जोड़ना चाहिए और बदले गए लेनदेन पर भी नज़र रखनी चाहिए। टकराव या पुष्टियाँ खोने पर ऐसी डिलीवरी रोकनी चाहिए जिसे वापस नहीं लिया जा सके। अपुष्ट बची रकम खर्च करने वाला अगला भुगतान भी पहले लेनदेन पर निर्भर है; वह उसकी सुरक्षा का स्वतंत्र प्रमाण नहीं है। Lightning Network, Bitcoin लेनदेन से धन डाले गए चैनलों में तेज़ भुगतान देता है। चैनल के दोनों पक्ष हस्ताक्षरित commitment लेनदेन का आदान-प्रदान करते हैं, जिनमें धन का बँटवारा दर्ज होता है। अपडेट के समय वे दूसरे पक्ष को ऐसी गुप्त जानकारी देते हैं जिससे बाद में पुरानी स्थिति प्रकाशित करने पर दंड लगाया जा सके। पुरानी स्थिति को इस तरह अमान्य करने की व्यवस्था revocation कहलाती है। सुरक्षा के लिए उस प्रयास का समय पर पता लगाना और जवाब देना जरूरी है। यह चेन पर अपुष्ट भुगतान देखकर सामान सौंपने से अलग व्यवस्था है। बिना पुष्टि खोला गया zero-conf channel जानबूझकर धन देने वाले पक्ष पर भरोसा करता है और उस धन के दोहरे खर्च का जोखिम समाप्त नहीं करता। [13] [14]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें लेनदेन, पुष्टि, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. इस प्रविष्टि का उल्लेख यहाँ भी है पुष्टि, Reorg, Stale Block, Replace-by-Fee (RBF).