बिटकॉइन: एक पीयर-टू-पीयर इलेक्ट्रॉनिक कैश सिस्टम

Abstract

इलेक्ट्रॉनिक कैश का एक पूर्णतः peer-to-peer संस्करण ऑनलाइन भुगतानों को किसी वित्तीय संस्थान से गुज़रे बिना सीधे एक पक्ष से दूसरे पक्ष को भेजने की अनुमति देगा। Digital signatures समाधान का एक हिस्सा प्रदान करती हैं, लेकिन यदि double-spending को रोकने के लिए अभी भी एक विश्वसनीय तृतीय पक्ष की आवश्यकता है, तो मुख्य लाभ खो जाते हैं। हम एक peer-to-peer network का उपयोग करके double-spending समस्या का समाधान प्रस्तावित करते हैं। यह network लेनदेन को hash-based proof-of-work की एक सतत श्रृंखला में hash करके उन्हें timestamp करता है, जिससे एक ऐसा रिकॉर्ड बनता है जिसे proof-of-work को दोबारा किए बिना बदला नहीं जा सकता। सबसे लंबी chain न केवल देखी गई घटनाओं के अनुक्रम के प्रमाण के रूप में कार्य करती है, बल्कि इस बात के प्रमाण के रूप में भी कि यह CPU शक्ति के सबसे बड़े पूल से आई है। जब तक CPU शक्ति का बहुमत उन nodes द्वारा नियंत्रित है जो network पर हमला करने के लिए सहयोग नहीं कर रहे हैं, वे सबसे लंबी chain उत्पन्न करेंगे और हमलावरों से आगे रहेंगे। network को स्वयं न्यूनतम संरचना की आवश्यकता है। संदेश best effort के आधार पर broadcast किए जाते हैं, और nodes अपनी इच्छा से network छोड़ सकते हैं और पुनः जुड़ सकते हैं, सबसे लंबी proof-of-work chain को उनकी अनुपस्थिति के दौरान जो हुआ उसके प्रमाण के रूप में स्वीकार करते हुए।

Introduction

इंटरनेट पर वाणिज्य इलेक्ट्रॉनिक भुगतानों को संसाधित करने के लिए विश्वसनीय तृतीय पक्ष के रूप में कार्य करने वाली वित्तीय संस्थाओं पर लगभग पूरी तरह से निर्भर हो गया है। हालांकि यह प्रणाली अधिकांश लेनदेन के लिए पर्याप्त रूप से काम करती है, फिर भी यह विश्वास-आधारित मॉडल की अंतर्निहित कमज़ोरियों से ग्रस्त है। पूर्णतः अपरिवर्तनीय लेनदेन वास्तव में संभव नहीं हैं, क्योंकि वित्तीय संस्थान विवादों में मध्यस्थता करने से बच नहीं सकतीं। मध्यस्थता की लागत लेनदेन की लागत बढ़ाती है, न्यूनतम व्यावहारिक लेनदेन आकार को सीमित करती है और छोटे सामान्य लेनदेन की संभावना को समाप्त करती है, और अपरिवर्तनीय सेवाओं के लिए अपरिवर्तनीय भुगतान करने की क्षमता के नुकसान में एक व्यापक लागत है। उलटने की संभावना के साथ, विश्वास की आवश्यकता फैलती है। व्यापारियों को अपने ग्राहकों से सतर्क रहना होगा, उनसे अन्यथा आवश्यक से अधिक जानकारी की मांग करनी होगी। धोखाधड़ी का एक निश्चित प्रतिशत अपरिहार्य के रूप में स्वीकार किया जाता है। इन लागतों और भुगतान अनिश्चितताओं को भौतिक मुद्रा का उपयोग करके व्यक्तिगत रूप से टाला जा सकता है, लेकिन किसी विश्वसनीय पक्ष के बिना संचार चैनल पर भुगतान करने का कोई तंत्र मौजूद नहीं है।

जो चाहिए वह एक इलेक्ट्रॉनिक भुगतान प्रणाली है जो विश्वास के बजाय cryptographic proof पर आधारित हो, जो किन्हीं भी दो इच्छुक पक्षों को किसी विश्वसनीय तृतीय पक्ष की आवश्यकता के बिना सीधे एक-दूसरे के साथ लेनदेन करने की अनुमति दे। जिन लेनदेन को उलटना कम्प्यूटेशनल रूप से अव्यावहारिक हो, वे विक्रेताओं को धोखाधड़ी से सुरक्षित करेंगे, और खरीदारों की सुरक्षा के लिए नियमित escrow तंत्र आसानी से लागू किए जा सकते हैं। इस पत्र में, हम लेनदेन के कालानुक्रमिक क्रम का कम्प्यूटेशनल प्रमाण उत्पन्न करने के लिए peer-to-peer distributed timestamp server का उपयोग करके double-spending समस्या का समाधान प्रस्तावित करते हैं। यह प्रणाली तब तक सुरक्षित है जब तक ईमानदार nodes सामूहिक रूप से किसी भी सहयोगी हमलावर nodes के समूह से अधिक CPU शक्ति को नियंत्रित करते हैं।

Transactions

हम एक इलेक्ट्रॉनिक coin को digital signatures की एक श्रृंखला के रूप में परिभाषित करते हैं। प्रत्येक स्वामी पिछले लेनदेन के hash और अगले स्वामी की public key को digitally sign करके और इन्हें coin के अंत में जोड़कर coin को अगले व्यक्ति को हस्तांतरित करता है। एक प्राप्तकर्ता स्वामित्व की श्रृंखला को सत्यापित करने के लिए signatures को सत्यापित कर सकता है।

समस्या यह है कि प्राप्तकर्ता यह सत्यापित नहीं कर सकता कि किसी एक स्वामी ने coin को double-spend नहीं किया। एक सामान्य समाधान एक विश्वसनीय केंद्रीय प्राधिकरण, या mint, की शुरुआत करना है, जो प्रत्येक लेनदेन में double spending की जांच करे। प्रत्येक लेनदेन के बाद, coin को एक नया coin जारी करने के लिए mint को वापस किया जाना चाहिए, और केवल सीधे mint से जारी किए गए coins पर double-spend न होने का भरोसा किया जाता है। इस समाधान की समस्या यह है कि संपूर्ण मौद्रिक प्रणाली का भाग्य mint चलाने वाली कंपनी पर निर्भर करता है, जिसमें प्रत्येक लेनदेन को उनके माध्यम से गुज़रना होता है, ठीक एक बैंक की तरह।

हमें प्राप्तकर्ता के लिए यह जानने का एक तरीका चाहिए कि पिछले स्वामियों ने कोई पूर्व लेनदेन sign नहीं किया। हमारे उद्देश्यों के लिए, सबसे पहला लेनदेन वह है जो मायने रखता है, इसलिए हमें बाद के double-spend प्रयासों की चिंता नहीं है। किसी लेनदेन की अनुपस्थिति की पुष्टि करने का एकमात्र तरीका सभी लेनदेन के बारे में जागरूक होना है। mint-आधारित मॉडल में, mint सभी लेनदेन के बारे में जागरूक था और तय करता था कि कौन सा पहले आया। किसी विश्वसनीय पक्ष के बिना इसे पूरा करने के लिए, लेनदेन को सार्वजनिक रूप से घोषित किया जाना चाहिए [^1], और हमें प्रतिभागियों के लिए उस क्रम के एकल इतिहास पर सहमत होने की एक प्रणाली की आवश्यकता है जिसमें उन्हें प्राप्त किया गया था। प्राप्तकर्ता को इस बात का प्रमाण चाहिए कि प्रत्येक लेनदेन के समय, अधिकांश nodes ने सहमति व्यक्त की कि यह पहले प्राप्त हुआ था।

Timestamp Server

हमारा प्रस्तावित समाधान एक timestamp server से शुरू होता है। एक timestamp server उन items के एक block का hash लेकर और उस hash को व्यापक रूप से प्रकाशित करके काम करता है, जैसे कि किसी समाचार पत्र या Usenet पोस्ट में [^2] [^3] [^4] [^5]। timestamp यह साबित करता है कि hash में शामिल होने के लिए डेटा उस समय अवश्य मौजूद रहा होगा। प्रत्येक timestamp अपने hash में पिछले timestamp को शामिल करता है, जिससे एक श्रृंखला बनती है, जिसमें प्रत्येक अतिरिक्त timestamp पहले वालों को मज़बूत करता है।

Proof-of-Work

peer-to-peer आधार पर एक distributed timestamp server को लागू करने के लिए, हमें समाचार पत्र या Usenet पोस्ट के बजाय Adam Back के Hashcash [^6] के समान एक proof-of-work प्रणाली का उपयोग करना होगा। proof-of-work में एक ऐसे मान की खोज शामिल है जिसे hash किए जाने पर, जैसे SHA-256 के साथ, hash एक निश्चित संख्या में zero bits से शुरू होता है। आवश्यक औसत कार्य आवश्यक zero bits की संख्या में exponential होता है और इसे एक single hash निष्पादित करके सत्यापित किया जा सकता है।

हमारे timestamp network के लिए, हम block में एक nonce को बढ़ाकर proof-of-work को लागू करते हैं जब तक कि एक ऐसा मान नहीं मिल जाता जो block के hash को आवश्यक zero bits देता है। एक बार CPU प्रयास proof-of-work को संतुष्ट करने के लिए खर्च किया जा चुका है, तो block को कार्य को दोबारा किए बिना बदला नहीं जा सकता। चूँकि बाद के blocks इसके बाद chain किए जाते हैं, block को बदलने के कार्य में इसके बाद के सभी blocks को दोबारा करना शामिल होगा।

proof-of-work बहुमत निर्णय लेने में प्रतिनिधित्व निर्धारित करने की समस्या को भी हल करता है। यदि बहुमत one-IP-address-one-vote पर आधारित होता, तो इसे कोई भी व्यक्ति जो कई IPs आवंटित करने में सक्षम है, विकृत कर सकता था। proof-of-work अनिवार्य रूप से one-CPU-one-vote है। बहुमत निर्णय सबसे लंबी chain द्वारा दर्शाया जाता है, जिसमें सबसे अधिक proof-of-work प्रयास निवेश किया गया है। यदि CPU शक्ति का बहुमत honest nodes द्वारा नियंत्रित है, तो honest chain सबसे तेज़ बढ़ेगी और किसी भी प्रतिस्पर्धी chains से आगे निकल जाएगी। किसी पिछले block को संशोधित करने के लिए, एक हमलावर को उस block और उसके बाद के सभी blocks के proof-of-work को दोबारा करना होगा और फिर honest nodes के कार्य को पकड़ना और पार करना होगा। हम बाद में दिखाएंगे कि एक धीमे हमलावर के पकड़ने की संभावना बाद के blocks जोड़े जाने के साथ exponentially घटती है।

बढ़ती hardware गति और समय के साथ nodes चलाने में बदलती रुचि की भरपाई के लिए, proof-of-work कठिनाई एक moving average द्वारा निर्धारित की जाती है जो प्रति घंटे blocks की औसत संख्या को लक्षित करती है। यदि वे बहुत तेज़ी से उत्पन्न होते हैं, तो कठिनाई बढ़ जाती है।

Network

network चलाने के चरण इस प्रकार हैं:

1. नए transactions सभी nodes को broadcast किए जाते हैं।
2. प्रत्येक node नए transactions को एक block में एकत्र करता है।
3. प्रत्येक node अपने block के लिए एक कठिन proof-of-work खोजने पर काम करता है।
4. जब एक node proof-of-work पाता है, तो वह block को सभी nodes को broadcast करता है।
5. nodes block को तभी स्वीकार करते हैं जब उसमें सभी transactions वैध हों और पहले से खर्च न किए गए हों।
6. nodes स्वीकृत block के hash को previous hash के रूप में उपयोग करते हुए, chain में अगला block बनाने पर काम करके block की अपनी स्वीकृति व्यक्त करते हैं।

nodes हमेशा सबसे लंबी chain को सही मानते हैं और उसे बढ़ाने पर काम करते रहते हैं। यदि दो nodes एक साथ अगले block के अलग-अलग संस्करण broadcast करते हैं, तो कुछ nodes को पहले एक या दूसरा प्राप्त हो सकता है। उस स्थिति में, वे पहले प्राप्त हुए पर काम करते हैं, लेकिन दूसरी branch को सहेज कर रखते हैं यदि वह लंबी हो जाए। जब अगला proof-of-work पाया जाता है और एक branch लंबी हो जाती है तो बराबरी टूट जाएगी; जो nodes दूसरी branch पर काम कर रहे थे वे फिर लंबी वाली पर स्विच कर लेंगे।

नए transaction broadcasts को सभी nodes तक पहुँचना आवश्यक नहीं है। जब तक वे कई nodes तक पहुँचते हैं, वे शीघ्र ही एक block में शामिल हो जाएंगे। block broadcasts भी छूटे हुए संदेशों के प्रति सहनशील हैं। यदि एक node को कोई block प्राप्त नहीं होता, तो जब उसे अगला block प्राप्त होता है और उसे पता चलता है कि उसने एक छोड़ दिया, तो वह उसका अनुरोध करेगा।

Incentive

परंपरा के अनुसार, एक block में पहला transaction एक विशेष transaction होता है जो block के निर्माता के स्वामित्व में एक नया coin शुरू करता है। यह nodes को network का समर्थन करने के लिए एक प्रोत्साहन जोड़ता है, और coins को प्रचलन में वितरित करने का एक तरीका प्रदान करता है, क्योंकि उन्हें जारी करने के लिए कोई केंद्रीय प्राधिकरण नहीं है। नए coins की एक निरंतर मात्रा का स्थिर जोड़ना सोने के खनिकों द्वारा सोने को प्रचलन में जोड़ने के लिए संसाधन खर्च करने के समान है। हमारे मामले में, यह CPU समय और बिजली है जो खर्च की जाती है।

प्रोत्साहन को transaction fees से भी वित्तपोषित किया जा सकता है। यदि किसी transaction का output मूल्य उसके input मूल्य से कम है, तो अंतर एक transaction fee है जो उस block के प्रोत्साहन मूल्य में जोड़ी जाती है जिसमें वह transaction शामिल है। एक बार पूर्वनिर्धारित संख्या में coins प्रचलन में आ जाने के बाद, प्रोत्साहन पूरी तरह से transaction fees में परिवर्तित हो सकता है और पूरी तरह से inflation मुक्त हो सकता है।

प्रोत्साहन nodes को ईमानदार बने रहने के लिए प्रोत्साहित करने में मदद कर सकता है। यदि एक लालची हमलावर सभी honest nodes से अधिक CPU शक्ति एकत्र करने में सक्षम है, तो उसे अपने भुगतानों को वापस चुराकर लोगों को धोखा देने के लिए इसका उपयोग करने, या नए coins उत्पन्न करने के लिए इसका उपयोग करने के बीच चुनना होगा। उसे नियमों के अनुसार खेलना अधिक लाभदायक लगना चाहिए, ऐसे नियम जो उसे बाकी सभी की तुलना में अधिक नए coins से अनुग्रहीत करते हैं, बजाय इसके कि वह प्रणाली और अपनी स्वयं की संपत्ति की वैधता को कमज़ोर करे।

Reclaiming Disk Space

एक बार किसी coin में नवीनतम transaction पर्याप्त blocks के नीचे दब जाता है, तो disk space बचाने के लिए इससे पहले के खर्च किए गए transactions को हटाया जा सकता है। block के hash को तोड़े बिना इसे सुगम बनाने के लिए, transactions को एक Merkle Tree [^7] [^2] [^5] में hash किया जाता है, जिसमें केवल root को block के hash में शामिल किया जाता है। पुराने blocks को फिर tree की branches को काटकर संकुचित किया जा सकता है। आंतरिक hashes को संग्रहीत करने की आवश्यकता नहीं है।

बिना transactions वाला एक block header लगभग 80 bytes का होगा। यदि हम मानें कि blocks हर 10 मिनट में उत्पन्न होते हैं, तो 80 bytes * 6 * 24 * 365 = प्रति वर्ष 4.2MB। 2008 तक कंप्यूटर सिस्टम आमतौर पर 2GB RAM के साथ बिकते हैं, और Moore's Law 1.2GB प्रति वर्ष की वर्तमान वृद्धि की भविष्यवाणी करता है, तो भंडारण कोई समस्या नहीं होनी चाहिए भले ही block headers को मेमोरी में रखना आवश्यक हो।

Simplified Payment Verification

पूर्ण network node चलाए बिना भुगतानों को सत्यापित करना संभव है। एक उपयोगकर्ता को केवल सबसे लंबी proof-of-work chain के block headers की एक प्रति रखने की आवश्यकता है, जो वह network nodes से तब तक क्वेरी करके प्राप्त कर सकता है जब तक वह आश्वस्त न हो जाए कि उसके पास सबसे लंबी chain है, और transaction को उस block से जोड़ने वाली Merkle branch प्राप्त करनी होगी जिसमें उसे timestamp किया गया है। वह स्वयं transaction की जाँच नहीं कर सकता, लेकिन इसे chain में एक स्थान से जोड़कर, वह देख सकता है कि एक network node ने इसे स्वीकार किया है, और इसके बाद जोड़े गए blocks आगे पुष्टि करते हैं कि network ने इसे स्वीकार किया है।

इस प्रकार, सत्यापन तब तक विश्वसनीय है जब तक honest nodes network को नियंत्रित करते हैं, लेकिन यदि network पर एक हमलावर का वर्चस्व हो जाए तो यह अधिक कमज़ोर है। जबकि network nodes स्वयं transactions को सत्यापित कर सकते हैं, सरलीकृत विधि को एक हमलावर के fabricated transactions द्वारा तब तक धोखा दिया जा सकता है जब तक हमलावर network पर हावी रह सकता है। इससे बचाव के लिए एक रणनीति यह होगी कि network nodes जब एक अमान्य block का पता लगाएं तो alerts स्वीकार किए जाएं, जो उपयोगकर्ता के software को पूर्ण block और सतर्क किए गए transactions को डाउनलोड करने के लिए प्रेरित करे ताकि असंगति की पुष्टि हो सके। जो व्यवसाय बार-बार भुगतान प्राप्त करते हैं वे संभवतः अधिक स्वतंत्र सुरक्षा और तेज़ सत्यापन के लिए अपने स्वयं के nodes चलाना चाहेंगे।

Combining and Splitting Value

हालांकि coins को व्यक्तिगत रूप से संभालना संभव होगा, एक हस्तांतरण में प्रत्येक cent के लिए एक अलग transaction बनाना अव्यावहारिक होगा। मूल्य को विभाजित और संयोजित करने की अनुमति देने के लिए, transactions में कई inputs और outputs होते हैं। सामान्यतः या तो एक बड़े पिछले transaction से एक single input होगा या छोटी राशियों को मिलाने वाले कई inputs होंगे, और अधिकतम दो outputs होंगे: एक भुगतान के लिए, और एक शेष राशि लौटाने के लिए, यदि कोई हो, प्रेषक को वापस।

यह ध्यान देने योग्य है कि fan-out, जहाँ एक transaction कई transactions पर निर्भर करता है, और वे transactions कई अन्य पर निर्भर करते हैं, यहाँ कोई समस्या नहीं है। किसी transaction के इतिहास की पूर्ण स्वतंत्र प्रति निकालने की कभी आवश्यकता नहीं होती।

Privacy

पारंपरिक बैंकिंग मॉडल सम्बंधित पक्षों और विश्वसनीय तृतीय पक्ष तक सूचना की पहुँच को सीमित करके गोपनीयता का एक स्तर प्राप्त करता है। सभी transactions को सार्वजनिक रूप से घोषित करने की आवश्यकता इस विधि को बाहर करती है, लेकिन सूचना के प्रवाह को किसी अन्य स्थान पर तोड़कर गोपनीयता बनाए रखी जा सकती है: public keys को anonymous रखकर। जनता देख सकती है कि कोई व्यक्ति किसी अन्य को एक राशि भेज रहा है, लेकिन transaction को किसी से जोड़ने वाली जानकारी के बिना। यह stock exchanges द्वारा जारी की गई सूचना के स्तर के समान है, जहाँ व्यक्तिगत trades का समय और आकार, "tape", सार्वजनिक किया जाता है, लेकिन यह बताए बिना कि पक्ष कौन थे।

एक अतिरिक्त firewall के रूप में, प्रत्येक transaction के लिए एक नई key pair का उपयोग किया जाना चाहिए ताकि उन्हें एक common owner से जोड़ने से रोका जा सके। कुछ linking multi-input transactions के साथ अभी भी अपरिहार्य है, जो आवश्यक रूप से प्रकट करते हैं कि उनके inputs एक ही owner के स्वामित्व में थे। जोखिम यह है कि यदि किसी key का owner प्रकट हो जाता है, तो linking उसी owner से संबंधित अन्य transactions को प्रकट कर सकती है।

Calculations

हम उस परिदृश्य पर विचार करते हैं जिसमें एक हमलावर honest chain से तेज़ एक वैकल्पिक chain उत्पन्न करने का प्रयास कर रहा है। भले ही यह पूरा हो जाए, यह प्रणाली को मनमाने परिवर्तनों के लिए खुला नहीं करता, जैसे शून्य से मूल्य बनाना या ऐसा धन लेना जो कभी हमलावर का नहीं था। nodes एक अमान्य transaction को भुगतान के रूप में स्वीकार नहीं करेंगे, और honest nodes कभी भी उन्हें शामिल करने वाले block को स्वीकार नहीं करेंगे। एक हमलावर केवल अपने स्वयं के transactions में से एक को बदलने का प्रयास कर सकता है ताकि उसने हाल ही में खर्च किया गया धन वापस ले सके।

honest chain और हमलावर chain के बीच की दौड़ को एक Binomial Random Walk के रूप में वर्णित किया जा सकता है। सफलता की घटना honest chain का एक block से विस्तार है, जो इसकी बढ़त को +1 बढ़ाता है, और विफलता की घटना हमलावर की chain का एक block से विस्तार है, जो अंतर को -1 कम करता है।

किसी दिए गए घाटे से हमलावर के पकड़ने की संभावना Gambler's Ruin समस्या के समान है। मान लीजिए असीमित credit वाला एक जुआरी घाटे से शुरू करता है और breakeven तक पहुँचने के लिए संभावित रूप से अनंत trials खेलता है। हम उसके कभी breakeven पहुँचने, या हमलावर के कभी honest chain तक पकड़ने की संभावना की गणना इस प्रकार कर सकते हैं [^8]:

p = probability an honest node finds the next block
q = probability the attacker finds the next block
q = probability the attacker will ever catch up from z blocks behind
``````

\[
qz =
\begin{cases}
1 & \text{if } p \leq q \\
\left(\frac{q}{p}\right) z & \text{if } p > q
\end{cases}
\]

हमारी इस धारणा को देखते हुए कि p  q, जैसे-जैसे हमलावर को पकड़ने के लिए blocks की संख्या बढ़ती है, संभावना exponentially गिरती है। यदि वह शुरू में भाग्यशाली छलांग नहीं लगाता, तो जैसे-जैसे वह पीछे रहता जाता है उसकी संभावनाएँ अत्यंत कम हो जाती हैं।

अब हम विचार करते हैं कि एक नए transaction के प्राप्तकर्ता को पर्याप्त रूप से निश्चित होने से पहले कितनी देर प्रतीक्षा करनी होगी कि प्रेषक transaction को बदल नहीं सकता। हम मानते हैं कि प्रेषक एक हमलावर है जो प्राप्तकर्ता को कुछ समय तक विश्वास दिलाना चाहता है कि उसने उसे भुगतान किया, फिर कुछ समय बीतने के बाद इसे अपने आप को वापस भुगतान करने के लिए बदल देता है। जब ऐसा होगा तो प्राप्तकर्ता को सतर्क किया जाएगा, लेकिन प्रेषक आशा करता है कि तब तक बहुत देर हो चुकी होगी।

प्राप्तकर्ता एक नई key pair उत्पन्न करता है और signing से कुछ समय पहले public key प्रेषक को देता है। यह प्रेषक को समय से पहले blocks की एक chain तैयार करने से रोकता है जिस पर वह लगातार काम करता रहे जब तक कि वह पर्याप्त आगे निकलने के लिए भाग्यशाली न हो जाए, फिर उस क्षण transaction निष्पादित करे। एक बार transaction भेज दिया जाता है, बेईमान प्रेषक अपने transaction के एक वैकल्पिक संस्करण वाली एक समानांतर chain पर गुप्त रूप से काम करना शुरू करता है।

प्राप्तकर्ता तब तक प्रतीक्षा करता है जब तक transaction एक block में जोड़ दिया जाता है और z blocks इसके बाद जोड़ दिए जाते हैं। उसे हमलावर द्वारा की गई प्रगति की सटीक मात्रा नहीं पता, लेकिन यह मानते हुए कि honest blocks ने प्रति block अपेक्षित औसत समय लिया, हमलावर की संभावित प्रगति अपेक्षित मूल्य वाला एक Poisson distribution होगी:

\[
\lambda = z\frac{q}{p}
\]

हमलावर के अभी भी पकड़ सकने की संभावना प्राप्त करने के लिए, हम उसकी प्रगति की प्रत्येक संभावित मात्रा के लिए Poisson density को उस बिंदु से पकड़ सकने की संभावना से गुणा करते हैं:

\[
\sum_{k=0}^{\infty} \frac{\lambda^k e^{-\lambda}}{k!} \cdot \left\{
\begin{array}{cl}
\left(\frac{q}{p}\right)^{(z-k)} & \text{if } k \leq z \\
1 & \text{if } k > z
\end{array}
\right.
\]

distribution की अनंत पूँछ के योग से बचने के लिए पुनर्व्यवस्थित करने पर...

\[
1 - \sum_{k=0}^{z} \frac{\lambda^k e^{-\lambda}}{k!} \left(1-\left(\frac{q}{p}\right)^{(z-k)}\right)
\]

C code में परिवर्तित करने पर...

```c
#include math.h

double AttackerSuccessProbability(double q, int z)
{
    double p = 1.0 - q;
    double lambda = z * (q / p);
    double sum = 1.0;
    int i, k;
    for (k = 0; k = z; k++)
    {
        double poisson = exp(-lambda);
        for (i = 1; i = k; i++)
            poisson *= lambda / i;
        sum -= poisson * (1 - pow(q / p, z - k));
    }
    return sum;
}

कुछ परिणाम चलाने पर, हम देख सकते हैं कि z के साथ संभावना exponentially गिरती है।

q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012

q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006

P को 0.1% से कम के लिए हल करने पर...

P  0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340

Conclusion

हमने विश्वास पर निर्भर किए बिना इलेक्ट्रॉनिक transactions के लिए एक प्रणाली प्रस्तावित की है। हमने digital signatures से बने coins के सामान्य ढाँचे से शुरुआत की, जो स्वामित्व का मज़बूत नियंत्रण प्रदान करता है, लेकिन double-spending को रोकने के तरीके के बिना अपूर्ण है। इसे हल करने के लिए, हमने transactions के सार्वजनिक इतिहास को रिकॉर्ड करने के लिए proof-of-work का उपयोग करने वाला एक peer-to-peer network प्रस्तावित किया जो तेज़ी से किसी हमलावर के लिए बदलना कम्प्यूटेशनल रूप से अव्यावहारिक हो जाता है यदि honest nodes CPU शक्ति के बहुमत को नियंत्रित करते हैं। network अपनी असंरचित सरलता में मज़बूत है। nodes सभी एक साथ न्यूनतम समन्वय के साथ काम करते हैं। उन्हें पहचाने जाने की आवश्यकता नहीं है, क्योंकि संदेश किसी विशेष स्थान पर रूट नहीं किए जाते और केवल best effort के आधार पर वितरित किए जाने की आवश्यकता है। nodes अपनी इच्छा से network छोड़ सकते हैं और पुनः जुड़ सकते हैं, proof-of-work chain को उनकी अनुपस्थिति के दौरान जो हुआ उसके प्रमाण के रूप में स्वीकार करते हुए। वे अपनी CPU शक्ति से मतदान करते हैं, वैध blocks पर काम करके उन्हें बढ़ाकर अपनी स्वीकृति व्यक्त करते हैं और अमान्य blocks पर काम करने से इनकार करके उन्हें अस्वीकार करते हैं। कोई भी आवश्यक नियम और प्रोत्साहन इस consensus mechanism के साथ लागू किए जा सकते हैं।

References