Gavin Andresen

प्रोजेक्ट के निर्माता के पीछे हटने पर सॉफ़्टवेयर अपना रखरखाव खुद नहीं करता। सुधारों, परीक्षण और नए संस्करणों के बीच तालमेल किसी को बैठाना होता है। Bitcoin के शुरुआती दौर में Satoshi के बाद Gavin Andresen ने यह जिम्मेदारी संभाली। 17 नवंबर 2015 की एक बैठक के लिए तैयार MIT का परिचय यही इतिहास बताता है और उस समय मुख्य रखरखावकर्ता के रूप में Wladimir van der Laan का नाम देता है। यह सॉफ़्टवेयर विकास की भूमिका है, नेटवर्क का स्वामित्व नहीं। पुराना परिचय आज रिपॉज़िटरी तक पहुँच का प्रमाण भी नहीं है। रिपॉज़िटरी वह साझा स्थान है जहाँ स्रोत कोड रखा जाता है। [1]

नया व्यक्ति डिजिटल पैसे की बात समझ सकता है, लेकिन सिक्के न हों तो उन्हें प्राप्त करना और भेजना कैसे आज़माए? Andresen ने Bitcoin Faucet से यह बाधा कम की। उन्होंने 11 जून 2010 को इसकी घोषणा की, शुरुआत में 1,100 BTC रखे और आज़माने के लिए पाँच सिक्के देने की पेशकश की। आने वाले व्यक्ति को खुद माइनिंग में सफल होने का इंतज़ार या विक्रेता की तलाश नहीं करनी पड़ती थी। Faucet पहले से मौजूद धन बाँटता था; वह नए बिटकॉइन या ब्लॉक पुरस्कार नहीं बनाता था। उद्देश्य पहला अनुभव आसान करना था, पैसे जारी करने के नियम बदलना नहीं। [2]

11 जून 2010 के एक उत्तर में Andresen ने सीमा स्पष्ट की: प्रति IP पते पर पाँच सिक्के, रोज़ नहीं। IP पता कंप्यूटर नेटवर्क में किसी कनेक्शन की पहचान करता है। वह न बिटकॉइन वॉलेट का पता है, न अलग-अलग लोगों की भरोसेमंद सूची। इसलिए सेवा की सुरक्षा करना पहचान सत्यापित करने के बराबर नहीं था। इंसान और स्वचालित प्रोग्राम में फर्क करने में मदद करने वाला काम, CAPTCHA, उस समय संभावित अतिरिक्त उपाय के रूप में चर्चा में था। इस शुरुआती व्यवस्था को बाद के बदलावों से अलग रखना चाहिए, न कि आज की ऐसी सेवाओं को देखकर उसका इतिहास दोबारा गढ़ना चाहिए। [2]

एक अन्य योगदान ने दूसरी व्यावहारिक समस्या हल की। पैसे पाने वाला व्यक्ति चाह सकता है कि उन्हें खर्च करने से पहले कई हस्ताक्षर जरूरी हों। क्या भेजने वाले को हर बार यह पूरा नियम संभालना चाहिए? 2012 का BIP 16, Pay to Script Hash बताता है: भुगतान उस स्क्रिप्ट के hash की ओर इशारा करता है जिसमें शर्तें हैं। Hash एक छोटा डिजिटल निशान है। BIP, Bitcoin में सुधार का क्रमांकित प्रस्ताव है। यहाँ redeemScript कहलाने वाली असली स्क्रिप्ट बाद में पैसा खर्च करने वाला देता है। शर्तें हटती नहीं; उन्हें कब और कौन प्रस्तुत करेगा, यह बदलता है। [3]

ऐसी तिजोरी सोचिए जिसे खोलने के लिए कई लोगों की सहमति चाहिए। उसके नियम दिखा देने से पैसे नहीं निकलते। इसी तरह 2012 का BIP 16 पहले प्रस्तुत redeemScript के hash की जाँच और फिर उसकी शर्तों को चलाने की माँग करता है। स्क्रिप्ट जानना जरूरी हस्ताक्षरों की जगह नहीं लेता। इस जोड़ी जाने वाली स्क्रिप्ट की तकनीकी सीमा 520 बाइट भी है; बाइट डेटा के आकार की इकाई है। नए पाठक के लिए दो जाँच अलग समझना महत्वपूर्ण है: सही नियम प्रस्तुत करना और उस नियम की माँग पूरी करने वाली चीज़ें होना। [3]

2015 में Andresen ने अधिकतम ब्लॉक आकार को धीरे-धीरे बढ़ाने के लिए BIP 101 प्रस्तुत किया। दस्तावेज़ इसे Hard Fork कहता है: ऐसा बदलाव जिसमें नए नियमों से स्वीकार्य कुछ ब्लॉक पुराने नियमों से अस्वीकार हो जाएँगे। सूची में इसका दर्जा Closed, यानी बंद है। इसके विपरीत BIP 16 का दर्जा Deployed, यानी लागू किया गया है। BIP का क्रमांक या प्रसिद्ध लेखक होना सक्रिय होने का प्रमाण नहीं है। प्रस्ताव पढ़ते समय यह भी देखना जरूरी है कि उसके नियम वास्तव में इस्तेमाल होने लगे या नहीं। [4] [3]

ब्लॉक बढ़ाने पर विवाद क्यों हुआ? बड़े ब्लॉक में अधिक लेन-देन आ सकते हैं, लेकिन उसका डेटा भेजना, प्राप्त करना और जाँचना भी पड़ता है। इसलिए 2015 का BIP 101 डेटा भेजने की लागत और बढ़ी जरूरतों से बड़े संचालकों को फायदा होने के जोखिम पर भी चर्चा करता है। धीमे कनेक्शन वाला व्यक्ति बड़ी माइनिंग कंपनी से अलग स्थिति में हो सकता है। तकनीकी प्रगति को लेकर लेखक की अपेक्षा प्रस्ताव के पक्ष में तर्क है, हर भविष्य की परिस्थिति के लिए मापा गया परिणाम नहीं। सवाल क्षमता और नेटवर्क को स्वतंत्र रूप से जाँच पाने के बीच संतुलन का है। [4]

Bitcoin.org समझाता है कि डेवलपर उपयोगकर्ताओं पर नियमों का बदलाव नहीं थोप सकते, क्योंकि लोग खुद चुनते हैं कि कौन सा सॉफ़्टवेयर चलाएँ। साथ काम करने के लिए प्रतिभागियों के नियम आपस में संगत रहने चाहिए। Andresen प्रस्ताव लिख सकते थे, कोड तैयार कर सकते थे और लोगों को समझा सकते थे, लेकिन सबके लिए Bitcoin एकतरफा नहीं बदल सकते थे। इसलिए हर योगदान को अलग परखना बेहतर है: सेवा ने क्या संभव बनाया, कोड ने क्या किया और नेटवर्क ने क्या अपनाया। पुराने योगदान अपने आप हर बाद के दावे को सही नहीं बनाते। [5]