Hashcash

अन्ना पावेल को ईमेल भेजना चाहती है। एक और प्रति भेजने में लगभग कोई खर्च नहीं आता। लेकिन लाखों विज्ञापन भेजने वाले को भी यही फायदा मिलता है। Hashcash छोटी-सी बाधा जोड़ता है: भेजने वाले का कंप्यूटर पहले गणना करके टिकट बनाए। इसकी कीमत समय और ऊर्जा है, डाकघर को दिया गया पैसा नहीं। Adam Back ने अपना कार्यान्वयन 28 मार्च 1997 को घोषित किया और 2002 में तकनीकी विवरण प्रकाशित किया। Cynthia Dwork और Moni Naor ऐसी ही सोच पर 1992 में शोध कर चुके थे। Hashcash नेटवर्क के दुरुपयोग को सीमित करने की इन्हीं कोशिशों का हिस्सा है। [1] [12]

हैश डेटा से निकाला गया एक डिजिटल निशान है जिसकी लंबाई तय होती है। अन्ना का प्रोग्राम टिकट में एक परीक्षण मान बदलता है और निशान फिर निकालता है, जब तक शुरुआत में पर्याप्त शून्य बिट न मिलें। बिट एक द्विआधारी अंक है: शून्य या एक। b शून्य माँगने पर हर कोशिश की सफलता की संभावना लगभग 2^-b होती है और औसतन 2^b कोशिशें लगती हैं। b = 20 पर औसतन 1048576 गणनाएँ करनी पड़ती हैं; हर बार ठीक यही संख्या पूरी करना ज़रूरी नहीं। कभी जल्दी सफलता मिलती है, कभी देर होती है। पावेल तैयार टिकट का हैश एक बार निकालकर जाँच सकता है, लेकिन उसकी जानकारी और स्वीकार करने की शर्तें भी जाँचनी होंगी। [10] [11]

अगर अन्ना एक टिकट को दस लाख संदेशों के साथ लगा सके, तो बाधा बेकार हो जाएगी। इसलिए टिकट में खास प्राप्तकर्ता या सेवा और तारीख होती है। प्राप्तकर्ता वैधता जाँचता है और स्वीकार किए टिकटों का रिकॉर्ड रखता है, ताकि replay यानी दोबारा इस्तेमाल को अस्वीकार कर सके। सिर्फ तारीख, या संदेश की सामग्री से जुड़ाव भी, उसी संदेश को फिर भेजने से नहीं रोकता। Hashcash में खर्च का साझा वैश्विक रजिस्टर नहीं है; संदेश प्राप्त करने वाली सेवा यह जाँच करती है। सही हैश का मतलब यह नहीं कि टिकट फिर स्वीकार किया जा सकता है। [11] [12]

प्राप्त करने वाली सेवा जरूरी कठिनाई तय करती है। हर अतिरिक्त शून्य बिट औसत काम को लगभग दोगुना कर देता है। कमजोर शर्त स्पैमर को खास नहीं रोकती; बहुत कड़ी शर्त आम लोगों पर भी बोझ डालती है। इसलिए 20 एक उदाहरण है, हमेशा के लिए तय सुरक्षा मानक नहीं। उतनी ही कोशिशों में पुराने फोन और तेज कंप्यूटर को अलग-अलग समय लगता है। सेवा को उपकरणों की क्षमता, वैधता की अवधि और अपनी क्षमता देखनी चाहिए। Hashcash सभी से एक जैसी तय संख्या में सेकंड खर्च नहीं करवाता। [10] [11]

गणना नेक उपयोगकर्ता और हमलावर में फर्क नहीं करती। बहुत-से कंप्यूटर या botnet, यानी कब्जे में लिए गए उपकरणों का नेटवर्क रखने वाला स्पैमर काम बाँट सकता है और कुछ खर्च दूसरों पर डाल सकता है। उधर आम उपयोगकर्ता की बैटरी भी खर्च होती है। Hashcash हमले के आर्थिक समीकरण बदलना चाहता है, स्पैम खत्म होने की गारंटी देना नहीं। टिकट संदेश को एन्क्रिप्ट नहीं करता, भेजने वाले की वास्तविक पहचान साबित नहीं करता और डिलीवरी की गारंटी भी नहीं देता। यह स्वीकार करने की एक शर्त है, जिसे सेवा दूसरे बचावों के साथ जोड़ सकती है। [10]

संस्करण 1 का प्रारूप 1:bits:date:resource:ext:rand:counter है। ये हिस्से संस्करण, बताया गया कठिनाई स्तर, तारीख, प्राप्तकर्ता या सेवा, विस्तार, एक यादृच्छिक मान और बदलता काउंटर बताते हैं। bits फ़ील्ड बताता है कि भेजने वाले के दावे के अनुसार हैश की शुरुआत में कितने शून्य बिट हैं, न कि कंप्यूटर ने वास्तव में कितनी कोशिशें कीं। इनके नाम तकनीकी प्रारूप का हिस्सा हैं, इसलिए अनुवाद करके बदले नहीं जाते। पुराने कार्यान्वयन में पूरे अक्षर-क्रम का SHA-1 निकाला जाता है। असली निशान को शर्त पूरी करनी चाहिए; bits में संख्या लिख देना काफी नहीं। यह ऐतिहासिक प्रारूप का वर्णन है, नई सुरक्षा प्रणालियों में SHA-1 अपनाने की सलाह नहीं। Bitcoin का डेटा प्रारूप और हैश फ़ंक्शन अलग हैं। [11] [13]

यहाँ ऐसा इनपुट खोजना है जिसके निशान की शुरुआत तय रूप में हो। ऐसे इनपुट को partial preimage कहते हैं: उसका हैश तय हिस्से की शर्त पूरी करता है, जबकि बाकी हिस्सा कुछ भी हो सकता है। इसके विपरीत, collision यानी टकराव में दो अलग इनपुट एक ही निशान देते हैं। कुछ पुराने लेख ढीला शब्द partial collision इस्तेमाल करते हैं, लेकिन काम समझने के लिए फर्क जरूरी है। SHA-1 के टकराव खोजने वाला हमला अपने आप तय शुरुआत खोजने की समस्या हल नहीं कर देता। फिर भी इससे SHA-1 आज की सामान्य सुरक्षा जरूरतों के लिए उचित विकल्प नहीं बन जाता। [10] [11] [13]

Hal Finney ने 2004 में RPOW, Reusable Proofs of Work पेश किया। उपयोगकर्ता काम का प्रमाण देकर नया टोकन ले सकता था। अगले हस्तांतरण में पुराना टोकन अमान्य होता और उसकी जगह नया मिलता। दोबारा उपयोग का अर्थ उसी टिकट की असीम प्रतियाँ बनाना नहीं था। व्यवस्था IBM 4758 सुरक्षित मॉड्यूल वाले सर्वर और चल रहे प्रोग्राम की दूर से जाँच पर निर्भर थी। इससे संचालक पर जरूरी भरोसा घटता था, लेकिन हार्डवेयर और निर्माता से जुड़ी धारणाएँ बनी रहती थीं। RPOW एक प्रयोगात्मक पूर्ववर्ती था, Bitcoin की विकेंद्रीकृत सहमति नहीं। [7] [15]

Bitcoin Whitepaper में Back के Hashcash का साफ संदर्भ है। सातोशी ने वही अंतर अपनाया: परिणाम खोजने में बार-बार कोशिश लगती है, लेकिन दूसरे उसे आसानी से जाँच लेते हैं। Bitcoin के माइनर वैध ब्लॉक हेडर खोजते हैं, जो लेनदेन के ब्लॉक का सार रखता है और पिछले ब्लॉक की ओर संकेत करता है। वे double SHA-256, यानी लगातार दो बार SHA-256 लागू करते हैं और परिणाम को target नाम की संख्यात्मक सीमा से मिलाते हैं। यह SHA-1 वाला ईमेल टिकट वॉलेट में रख देना नहीं है। साझा चीज सिद्धांत है, पूरी प्रणाली नहीं। [8] [14]

डाक शुल्क एक अनुरोध की लागत तय करता है। पैसे को यह भी तय करना होता है कि दो परस्पर विरोधी हस्तांतरणों में कौन वैध है। Bitcoin ब्लॉकों को जोड़ता है और उसके नोड वैध शाखाओं में सबसे अधिक संचित काम वाली चेन चुनते हैं। नोड नियम जाँचने वाले कंप्यूटर हैं; वे लेनदेन और अनुमत मुद्रा निर्गम भी जाँचते हैं। बहुत बड़ी मात्रा में काम भी अमान्य लेनदेन को वैध नहीं बना सकता। Hashcash ने महत्वपूर्ण हिस्सा दिया; दूसरे नियमों के साथ जुड़कर ही बिना केंद्रीय संचालक के साझा मौद्रिक इतिहास संभव हुआ। [8] [9]