Bitcoin Whitepaper वह दस्तावेज़ है जिसमें Satoshi Nakamoto ने Bitcoin की रूपरेखा पेश की। उन्होंने 31 अक्टूबर 2008 को Bitcoin: A Peer-to-Peer Electronic Cash System शीर्षक से इसकी घोषणा की। संदर्भों सहित इसके नौ पन्ने बताते हैं कि डिजिटल हस्ताक्षर, भुगतान का सार्वजनिक रिकॉर्ड और कंप्यूटिंग का काम मिलकर बिना केंद्रीय संचालक की व्यवस्था कैसे बना सकते हैं। यह शुरुआती विचार की व्याख्या है, आज के सॉफ़्टवेयर की पूरी निर्देशिका या हर Bitcoin सेवा की सुरक्षा की गारंटी नहीं।
Whitepaper किसी समस्या को समझाकर उसका समाधान प्रस्तावित करता है। Bitcoin का दस्तावेज़ एक रोजमर्रा के सवाल से शुरू होता है: जब मैं इंटरनेट पर पैसे भेजता हूँ, तो क्या हमारे बीच हमेशा बैंक या दूसरा संचालक होना चाहिए? Satoshi ने 31 अक्टूबर 2008 को क्रिप्टोग्राफी मेलिंग सूची में अपना प्रस्ताव भेजा और दस्तावेज़ का लिंक दिया। उन्होंने bitcoin की कीमत या निवेशक के मुनाफे का वादा नहीं किया। उन्होंने समझाया कि भुगतान के इतिहास का निर्णय एक कंपनी को सौंपे बिना पैसे कैसे लिए जा सकते हैं। यही समस्या पूरे दस्तावेज़ को जोड़ती है। [2] [1]
कल्पना कीजिए कि भेजने वाला दो अलग भुगतानों पर हस्ताक्षर करता है और दोनों में वही पैसे खर्च होते हैं। एक प्राप्तकर्ता पहला भुगतान देखता है, दूसरा अगला। दोनों सही डिजिटल हस्ताक्षर, यानी भुगतान करने के अधिकार का प्रमाण जाँच सकते हैं, लेकिन पैसे दोनों को नहीं मिल सकते। इंटरनेट पर डेटा की नकल आसान है; अकेला हस्ताक्षर इसे नहीं रोकता। इसलिए खंड 2 पैसे खर्च करने के अधिकार और साझा इतिहास में कौन-सा भुगतान आएगा, इन सवालों को अलग रखता है। Bitcoin हस्ताक्षरों के साथ सार्वजनिक रिकॉर्ड जोड़ता है, जिससे पहले खर्च हो चुके पैसे पहचाने जा सकें। [1]
खंड 3–5 भुगतानों को ब्लॉक में जोड़ने का तरीका बताते हैं। हर नया ब्लॉक hash के जरिए पिछले ब्लॉक की ओर संकेत करता है। Hash डेटा की छोटी डिजिटल छाप है। पुराना रिकॉर्ड बदलने से छाप बदल जाएगी और कड़ियाँ टूटेंगी। Proof of Work इसमें महँगा कंप्यूटिंग काम जोड़ता है: स्वीकार्य ब्लॉक बनाने के लिए बहुत कोशिशें चाहिए, लेकिन नतीजा जाँचना आसान है। विरोधी शाखाओं में इसलिए नियम मानने वाले इतिहास का संचित काम मायने रखता है, बनाए गए खातों या IP पतों की संख्या नहीं। दस्तावेज़ इसे सबसे लंबी श्रृंखला कहता है। बहुत अधिक काम भी अमान्य लेनदेन को मान्य नहीं बनाता। श्रृंखला घटनाओं का क्रम तय करती है, हर भुगतान का सटीक समय नहीं। [1] [3]
कंप्यूटर और बिजली की लागत होती है। इसलिए खंड 6 आर्थिक प्रोत्साहन जोड़ता है: स्वीकार किए गए ब्लॉक का निर्माता नए जारी सिक्के और उसमें शामिल भुगतानों के शुल्क पा सकता है। शुल्क लेनदेन द्वारा खर्च किए गए मूल्य और नए आउटपुट के मूल्य का अंतर है। यह शून्य से बने अतिरिक्त सिक्के नहीं हैं। दस्तावेज़ ऐसा भविष्य भी सोचता है जिसमें केवल शुल्क इनाम का स्रोत होंगे। पर प्रस्ताव की सीमा जानना जरूरी है: whitepaper में 21 मिलियन की सटीक सीमा या हर 210,000 ब्लॉक पर आधा होने का नियम नहीं दिया गया। इन्हें Bitcoin के दूसरे स्रोतों से जाँचना होता है। [1] [3]
हर व्यक्ति सभी लेनदेन डाउनलोड और सत्यापित नहीं करना चाहता। इसलिए खंड 8 में SPV, यानी सरल भुगतान सत्यापन का प्रस्ताव है। क्लाइंट ब्लॉक हेडर लेता है, जिनमें ब्लॉक की मुख्य संक्षिप्त जानकारी होती है, और Merkle प्रमाण पाता है: hash की ऐसी कड़ी जो किसी लेनदेन का ब्लॉक में होना साबित करती है। यह किसी खास किताब में एक रिकॉर्ड होने की जाँच और पूरी किताब की शुद्धता जाँचने के अंतर जैसा है। शामिल होने का प्रमाण अकेला सभी नियम या पूरा खर्च इतिहास नहीं जाँचता। Whitepaper यह सीमा स्वीकार करता है: सरल क्लाइंट कुछ हमलों के सामने स्वयं लेनदेन जाँचने वाले Full Node से अधिक कमजोर होता है। [1]
बैंकिंग में भुगतान रिकॉर्ड का बड़ा हिस्सा सार्वजनिक नहीं होता। Bitcoin को साझा इतिहास चाहिए, इसलिए गोपनीयता अलग तरह से बचानी होती है। खंड 10 भुगतान को कुंजी धारक की पहचान से अलग रखने की बात करता है और आगे के लेनदेन के लिए नए कुंजी जोड़े सुझाता है। वह कमजोरी भी मानता है: भुगतान आपस में जोड़े जा सकते हैं। किसी एक रिकॉर्ड से व्यक्ति की पहचान होने पर दूसरे भुगतान भी खुल सकते हैं। इसलिए नया पता जादुई नकाब नहीं है। वह कुछ संबंध घटाता है, लेकिन सार्वजनिक इतिहास या दूसरे पक्ष को ज्ञात जानकारी को अपने आप मिटा नहीं देता। [1]
खंड 11 पूछता है कि हमलावर के ईमानदार प्रतिभागियों की श्रृंखला को पकड़ लेने की कितनी संभावना है। ऐसी दौड़ सोचिए जिसमें एक पक्ष आगे है और दोनों काम जारी रखते हैं। वर्णित मॉडल में हमलावर का कंप्यूटिंग हिस्सा जितना कम और श्रृंखला की बढ़त जितनी बड़ी, पकड़ने की संभावना उतनी कम होती है। गणना मान्यताओं और Poisson सन्निकटन का उपयोग करती है, जो किसी अवधि में घटनाओं की संख्या आँकने का गणितीय सरलीकरण है। यह हर वास्तविक हमले का पूर्वानुमान नहीं है। इसलिए तालिका का एक अंक निकालकर उसे हर भुगतान के लिए सुरक्षित पुष्टि संख्या नहीं माना जा सकता। [1]
दस्तावेज़ मूल रूपरेखा समझाता है। नेटवर्क और सॉफ़्टवेयर बाद में विकसित हुए; उदाहरण के लिए BIP 141 प्रस्ताव में वर्णित SegWit इसमें नहीं है। BIP सुधार का प्रस्ताव बताने वाला दस्तावेज़ है, ऐसा निर्णय नहीं जो प्रकाशित होते ही नेटवर्क का नियम बन जाए। आज के तकनीकी सवालों में प्रस्ताव, प्रोग्राम, वास्तव में लागू साझा नियम और लेनदेन आगे भेजने के नोड के स्थानीय निर्णय को अलग रखना जरूरी है। नोड किसी लेनदेन को आगे न भेजकर बाद में मान्य ब्लॉक में स्वीकार कर सकता है। दोनों स्थितियाँ विरोधाभासी नहीं हैं। [4] [3]
सार से शुरू करें और सवाल समझें कि संचालक के बिना दोहरा खर्च कैसे रोकें। फिर देखें कि हस्ताक्षर, साझा इतिहास और ब्लॉक बनाने का काम जवाब में क्या जोड़ते हैं। गणित रोक दे तो तुरंत हर सूत्र समझना जरूरी नहीं: पहले जानें कि गणना किस हमले का मॉडल है और किन मान्यताओं पर टिकी है। विवरण पर बाद में लौट सकते हैं। मूल ईमेल बताता है कि Satoshi ने प्रस्ताव कब पेश किया; PDF उसका तर्क देता है। संदर्भ से अलग की गई एक पंक्ति यह साबित नहीं करती कि कोई खास वॉलेट या सेवा जरूर सुरक्षित है। [2] [1]
मुख्य बात खंडों के नाम याद करना नहीं, बल्कि यह समझना है कि कोई हिस्सा अकेला पर्याप्त क्यों नहीं: हस्ताक्षर अधिकार दिखाता है, सार्वजनिक इतिहास दोहरा खर्च पहचानने में मदद करता है और Proof of Work क्रम दोबारा लिखना कठिन बनाता है। अलग हिस्सों का पहले का काम मौजूद था, जिसका Satoshi संदर्भों में उल्लेख करते हैं। योगदान उन्हें जोड़ने के तरीके में है। खास मान्यताओं वाला तर्कपूर्ण प्रस्ताव मानकर पढ़ें तो whitepaper आज भी Bitcoin की सोच का अच्छा परिचय है। यह मूल्य-सूची, निवेश निर्देशिका या आज Bitcoin नाम वाली हर व्यवस्था और उपकरण के नियमों का पूरा विनिर्देश नहीं है। [1]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Satoshi Nakamoto, Bitcoin, Proof of Work, लेनदेन, Timechain / Blockchain. इस प्रविष्टि का उल्लेख यहाँ भी है Bitcoin, Satoshi Nakamoto, Genesis Block, Cypherpunks.