Soft Fork

मान लीजिए अन्ना और पावेल अपने-अपने कंप्यूटर पर Bitcoin की जाँच करते हैं। अन्ना ने सॉफ्टवेयर अपडेट कर लिया है, पावेल ने अभी नहीं। अब BIP66 जैसा बदलाव आता है: कुछ बिटकॉइन खर्च करने का अधिकार साबित करने वाले डिजिटल हस्ताक्षरों का प्रारूप अधिक सटीक होना चाहिए। पहले स्वीकार की जाने वाली कुछ एन्कोडिंग अब स्वीकार नहीं होंगी। नए अनिवार्य प्रारूप में वैध हस्ताक्षर वाला भुगतान दोनों कंप्यूटर पर इस जाँच में सफल होगा। लेकिन हस्ताक्षर पहले अनुमत और अब निषिद्ध एन्कोडिंग में हो, तो अन्ना उसे अस्वीकार करेगी, जबकि पावेल अब भी स्वीकार कर सकता है। यहाँ हम मान रहे हैं कि भुगतान बाकी सभी नियम पूरे करता है। यही Soft Fork का मूल है: नए नियम कुछ और मामलों को रोकते हैं, लेकिन ऐसा कुछ नहीं खोलते जिसे पुराने नियम रोकते थे। जब तक माइनर सख्त नियमों के अनुसार ब्लॉक बनाते हैं, दोनों उस चेन का अनुसरण कर सकते हैं। फिर भी पावेल अतिरिक्त शर्त खुद नहीं जाँच रहा है। इसलिए Soft Fork से सभी नोड एक साथ अपडेट किए बिना Bitcoin में बदलाव संभव है। इसका अर्थ यह नहीं कि पुराना सॉफ्टवेयर नए जितनी पूरी जाँच करता है; न ही इससे अपने-आप दूसरी मुद्रा बन जाती है। [1] [6]

Full Node वह कंप्यूटर है जो Bitcoin के नियमों की स्वतंत्र जाँच करता है। वैध शाखाओं में से चुनते समय वह माइनिंग से साबित संचित कार्य की तुलना करता है, समर्थकों के वोट की नहीं। पुराना Full Node चेन का अनुसरण कर सकता है, क्योंकि अपडेट किए गए माइनर आम तौर पर उसके नियमों के अनुसार भी वैध ब्लॉक बनाते हैं। लेकिन वह नई शर्त नहीं जाँचता। नई शर्त तोड़ने वाली अधिक संचित कार्य की शाखा को पुराना नोड स्वीकार कर सकता है, जबकि अपडेट किए गए नोड उसे अस्वीकार करेंगे। नई सुरक्षा चाहिए तो अपना सत्यापन सॉफ्टवेयर अपडेट करना होगा। भुगतान प्राप्त करना, पता पहचानना और सारे सहमति नियम जाँचना अलग क्षमताएँ हैं। [1] [12]

BIP एक क्रमांकित तकनीकी प्रस्ताव है। उसे प्रकाशित करने भर से नेटवर्क नहीं बदलता: सॉफ्टवेयर बनाना और जाँचना होता है, फिर उपयोगकर्ता तय करते हैं कि उसे चलाएँगे या नहीं। Mainnet Bitcoin का मुख्य नेटवर्क है, जिस पर असली बिटकॉइन भेजे जाते हैं। सक्रियण तय करता है कि अपडेट किए गए नोड कब से नई शर्त का पालन अनिवार्य करेंगे। इसलिए प्रोग्राम में कोड मौजूद होना और ब्लॉक जाँचते समय उसका इस्तेमाल होना अलग बातें हैं। यहाँ बताई गई प्रक्रियाओं में lock-in का मतलब है कि आगे होने वाले सक्रियण की शर्त पूरी हो गई है; नियम खुद अभी लागू होना जरूरी नहीं। नोड उसे ACTIVE स्थिति में पहुँचने पर जाँचता है। वह अपनी शाखा के पिछले ब्लॉकों से स्थिति निकालता है। सक्रियण की सीमा के पास पुनर्गठन से यह इतिहास बदल जाए, तो गणना का परिणाम भी बदल सकता है। इसलिए अलग सक्रियण पैरामीटर वाले दो प्रोग्राम एक ही समय पर अलग ब्लॉक स्वीकार कर सकते हैं। [2] [15]

माइनर अपने नए ब्लॉक को पिछले ब्लॉक पर बनाता है; पिछले ब्लॉक को parent भी कहते हैं। उसे जाँचे बिना माइनर ऐसी शाखा पर मेहनत बर्बाद कर सकता है जिसे बाकी नोड अस्वीकार कर दें। जुलाई 2015 में कुछ माइनर BIP66 का संकेत दे रहे थे, लेकिन जिस पिछले ब्लॉक पर नया ब्लॉक बना रहे थे, उसकी पूरी जाँच नहीं कर रहे थे। उन्होंने एक अवैध ब्लॉक को आगे बढ़ाया और 4 जुलाई को छह ब्लॉक की अवैध शाखा बनाई; अगले दिन एक छोटी शाखा और बनी। अपडेट किए गए सत्यापन नोड ने दोनों को अस्वीकार किया। संस्करण का बिट या संख्या माइनर का दावा है, इसका प्रमाण नहीं कि उसने ब्लॉक के प्रारूप, पिछले ब्लॉक और लेन-देन की स्वतंत्र जाँच की है। [6] [14]

आपका नोड वास्तव में कौन-से नियम लागू करता है, यह जानने के लिए उसके सॉफ्टवेयर संस्करण और उसी से मिलने वाली जानकारी से शुरू करें। संस्करण के अनुसार getdeploymentinfo और getblockchaininfo लागू किए जाने वाले बदलावों और चेन के बारे में जानकारी देते हैं। उस संस्करण के दस्तावेज, सक्रियण की ऊँचाई और लॉग के साथ इन्हें पढ़ने से तैयार नियम और पहले से सक्रिय नियम का फर्क समझ आता है। वेब पर ब्लॉक एक्सप्लोरर किसी दूसरी सेवा का दृष्टिकोण दिखाता है; वह इस बात का प्रमाण नहीं कि आपका कंप्यूटर क्या जाँचता है। Hashrate माइनिंग की गणना-क्षमता बताता है। इससे माइनरों को आपके नोड के नियम तोड़ने का अधिकार नहीं मिलता। ACTIVE स्थिति में अपडेट किया गया नोड नई शर्त तोड़ने वाला ब्लॉक अस्वीकार करता है, भले ही उसके पीछे अधिकांश माइनिंग क्षमता हो। चेन का विभाजन बना रहेगा या नहीं, यह हर शाखा के संचित कार्य और उसके आर्थिक उपयोग पर भी निर्भर है। लागू पाबंदी को बस हटा देने से अभी अवैध ब्लॉक फिर स्वीकार्य हो जाएँगे, इसलिए यह Hard Fork होगा। सक्रियण से पहले समन्वित सॉफ्टवेयर संस्करण से पैरामीटर बदले जा सकते हैं, लेकिन वह बदलाव भी दूसरों के नोड पर अपने-आप स्थापित नहीं होता। [1] [15] [16]

V(पुराना) में वे सभी ब्लॉक हैं जिन्हें अपडेट से पहले के नियम स्वीकार करते हैं। बदलाव तभी Soft Fork है जब V(नया) इसी के भीतर हो: नया नोड कुछ और मामलों को अस्वीकार करता है, लेकिन नए नियम पूरे करने वाला हर ब्लॉक पुरानी जाँच भी पार करता है। नाम नियमों की संगतता बताता है, न कि बदलाव छोटा, सुरक्षित या सबको स्वीकार्य है। पुराने नोड को दिखने वाली सीमा बढ़ाना या पहले अवैध खर्च को अनुमति देना समुच्चय फैलाता है और आम तौर पर Hard Fork माँगता है। [1] [17]

सख्त नियम नई सुविधा भी जोड़ सकते हैं। BIP66 ने हस्ताक्षर डेटा के एन्कोडिंग प्रारूप DER को सटीक किया। BIP65 और BIP112 ने चुने हुए NOP कमांड में खर्च की समय-संबंधी शर्तें जोड़ीं; पहले ये कोई शर्त लागू नहीं करते थे। SegWit ने witness प्रोग्राम और witness नाम के सत्यापन डेटा पेश किए, जिनमें हस्ताक्षर भी शामिल हैं। बाद में Taproot ने इनके आरक्षित संस्करण 1 का उपयोग किया। पुराने नोड संबंधित नई शर्तें नहीं जाँचते। Anyone-can-spend इसी सीमित दृष्टि का वर्णन है, अपडेट किए गए नोड को चकमा देकर दूसरे की रकम खर्च करने का रास्ता नहीं। SegWit, witness commitment के जरिए witness डेटा को ब्लॉक से क्रिप्टोग्राफिक रूप से जोड़ता भी है। यह संबंध coinbase लेन-देन में दर्ज होता है, यानी माइनर का पुरस्कार रखने वाले पहले लेन-देन में, और पुराने मूल ब्लॉक के नियमों से संगतता बनाए रखता है। [6] [5] [7] [8] [12]

बिट का मान 0 या 1 होता है। ब्लॉक हेडर में संस्करण दर्ज करने वाले nVersion फ़ील्ड के अलग-अलग बिट माइनर की तैयारी का संकेत दे सकते हैं। BIP9 हर बदलाव के लिए एक नाम, खास बिट, शुरुआती समय और अंतिम समय तय करता है। मूल mainnet प्रक्रिया 2016 ब्लॉक की अवधियाँ जाँचती है। STARTED के दौरान कम से कम 1916 ब्लॉक, यानी 95 %, संकेत दें, तो अगली अवधि LOCKED_IN में जाती है। एक और अवधि के इंतजार के बाद ACTIVE आता है। समय-सीमा से पहले शर्त पूरी न हो, तो प्रक्रिया FAILED में समाप्त हो सकती है। शुरू होने से पहले की स्थिति DEFINED कहलाती है। हर नोड पिछले ब्लॉकों से स्थितियों का यह क्रम निकालता है। इसलिए किसी ब्लॉक का अपना nVersion यह तय नहीं करता कि उस पर नया नियम लागू है या नहीं। संकेत बदलाव का समय मिलाने में मदद करते हैं; वे अलग-अलग ब्लॉक की वैधता पर मतदान नहीं हैं। Lock-in हो जाने पर बाद के संकेत इस प्रक्रिया का परिणाम नहीं बदलते। [2]

Versionbits से माइनर अपनी तैयारी का संकेत देते हैं; इससे उन्हें दूसरे नोड के नियम बदलने का अधिकार नहीं मिलता। BIP8 समय की सीमाओं के बजाय ब्लॉक की ऊँचाइयाँ इस्तेमाल करता है। अगर lockinontimeout का मान true हो और अभी lock-in न हुआ हो, तो अंतिम अवधि MUST_SIGNAL में जा सकती है, जहाँ संकेत देना अनिवार्य है। BIP148 ने भाग लेने वाले नोड से उन ब्लॉक को अस्वीकार करने को कहा जो SegWit का संकेत नहीं देते थे। BIP91 ने इस बदलाव में तालमेल के लिए माइनरों की संकेत-सीमा कम रखी। नियम लागू करने, hashrate और आर्थिक स्वीकार्यता में मतभेद हों तो चेन बँट सकती है। इसलिए सक्रियण की विधि चुनने में सुरक्षा के पहलुओं को तौलना पड़ता है। [11] [9] [10] [17]

P2SH (BIP16) में रकम ऐसे स्क्रिप्ट के हैश पर भेजी जा सकती है जो बाद में उसे खर्च करने की शर्तें बताता है। स्क्रिप्ट इन शर्तों वाला एक प्रोग्राम है। 2012 में इसे लाते समय coinbase लेन-देन के संकेतों से माइनरों की तैयारी का आकलन किया गया। लेकिन नई जाँच लागू होने की सीमा ब्लॉकों के तय टाइमस्टैम्प से जुड़ी थी; संकेत जाँच का विकल्प नहीं थे। Coinbase ब्लॉक का पहला लेन-देन है और उसमें माइनर का पुरस्कार होता है। बाद के बदलावों ने ब्लॉक संस्करण और संकेतों की सीमाएँ इस्तेमाल कीं। BIP34 ने coinbase में ब्लॉक की ऊँचाई, यानी चेन में उसका स्थान, दर्ज करना अनिवार्य किया। BIP66 ने हस्ताक्षरों का DER प्रारूप सख्त किया और BIP65 ने CHECKLOCKTIMEVERIFY से खर्च की अनुमति देने वाले सबसे शुरुआती समय या ऊँचाई की जाँच जोड़ी। संस्करण संख्या को लगातार बढ़ाने से स्वतंत्र बदलावों को साथ-साथ लागू करना कठिन था, इसलिए BIP9 ने अलग बिट दिए। 2016 में ऊँचाई 419328 पर BIP68, BIP112 और BIP113 एक साथ सक्रिय हुए, लेकिन उनकी समय-संबंधी शर्तें अलग हैं। BIP68 खर्च किए जाने वाले आउटपुट की पुष्टि से गिनी जाने वाली सापेक्ष प्रतीक्षा जोड़ता है। BIP112 स्क्रिप्ट में CHECKSEQUENCEVERIFY, या CSV, से इस इंतजार की शर्त रखने देता है। इसके विपरीत BIP113 लेन-देन के निरपेक्ष समय-लॉक का समय-आधार बदलता है: जाँचे जा रहे ब्लॉक के टाइमस्टैम्प की जगह Median Time Past, यानी पिछले 11 ब्लॉकों के टाइमस्टैम्प का मध्यक, इस्तेमाल होता है। साथ सक्रिय होने का मतलब यह नहीं कि तीनों प्रस्ताव एक ही सापेक्ष लॉक जोड़ते हैं। [3] [4] [5] [6] [7] [18] [19] [20]

SegWit अगस्त 2017 में ऊँचाई 481824 पर सक्रिय हुआ। उसने हस्ताक्षर जैसे witness सत्यापन डेटा को लेन-देन के उस हिस्से से अलग किया जिससे पहचानकर्ता txid निकाला जाता है। यह क्यों जरूरी है? पुरानी एन्कोडिंग में कोई व्यक्ति हस्ताक्षर का लिखा हुआ रूप बदलकर लेन-देन का पहचानकर्ता बदल सकता था, जबकि किसे कितना भुगतान किया जा रहा है, वह वही रहता था। इस संभावना को malleability कहते हैं। सिर्फ witness डेटा बदलने से txid नहीं बदलता; लेकिन इस तरीके से पुराने प्रारूप वाले इनपुट की समस्या दूर नहीं होती। पुराना नोड लेन-देन को witness के बिना देखता है और witness v0 प्रोग्राम को anyone-can-spend मानता है। अपडेट किया गया नोड witness और हस्ताक्षर डाइजेस्ट भी जाँचता है; डाइजेस्ट हस्ताक्षर किए जाने वाले डेटा का डिजिटल निशान है। Coinbase आउटपुट में रखा witness commitment, witness डेटा को ब्लॉक से क्रिप्टोग्राफिक रूप से जोड़ता है, जिससे पूरी जाँच में बदलाव या डेटा हटाने का पता चलता है। Weight का मतलब ब्लॉक की क्षमता में डेटा गिनते समय उसका भार है। इससे प्रभावी क्षमता बढ़ी, जबकि पुराने नोड को दिखने वाला मूल ब्लॉक एक मेगाबाइट की मूल सीमा के भीतर रहा। [8]

Key-path में आउटपुट की कुंजी के अनुरूप हस्ताक्षर से खर्च होता है; script-path में उजागर स्क्रिप्ट की शर्तें पूरी करनी होती हैं। Schnorr हस्ताक्षर विधि है और Tapscript इन स्क्रिप्ट की भाषा है। BIP341 और BIP342 native SegWit आउटपुट के 32 बाइट लंबे witness v1 प्रोग्राम के लिए Schnorr हस्ताक्षरों और Tapscript के साथ key-path तथा script-path खर्च के नियम तय करते हैं। पुराना नोड इसे anyone-can-spend मानता है: संगतता बनी रहती है, पूरी जाँच नहीं। Speedy Trial ने संशोधित BIP9, 2016 में से 1815 ब्लॉक के संकेतों की सीमा (90%) और न्यूनतम सक्रियण ऊँचाई 709632 इस्तेमाल की। Taproot वहाँ 14 नवंबर 2021 को सक्रिय हुआ। नियम और सक्रियण की विधि की समीक्षा अलग-अलग करनी चाहिए। [12] [13] [16]