इस सप्ताह का समाचार पत्र पिछले सप्ताह BTCD और LND को प्रभावित करने वाले ब्लॉक पार्सिंग बग का वर्णन करता है, शुल्क द्वारा प्रतिस्थापित करने से संबंधित एक नियोजित Bitcoin Core फीचर परिवर्तन के बारे में चर्चा को सारांशित करता है, Bitcoin पर वैधता रोलअप के बारे में शोध की रूपरेखा तैयार करता है, MuSig2 के लिए मसौदा BIP में एक भेद्यता के बारे में एक घोषणा साझा करता है। एक अपुष्ट लेनदेन के न्यूनतम आकार को कम करने के प्रस्ताव की जांच करता है जिसे Bitcoin Core रिले करेगा, और Bitcoin के लिए संस्करण 2 एन्क्रिप्टेड ट्रांसपोर्ट प्रोटोकॉल के लिए BIP324 प्रस्ताव के अपडेट से लिंक करता है। सेवाओं और क्लाइंट सॉफ़्टवेयर में परिवर्तनों के सारांश के साथ हमारे नियमित खंड भी शामिल हैं, नई रिलीज़ और रिलीज़ उम्मीदवारों की घोषणाएँ, और लोकप्रिय Bitcoin इन्फ्रास्ट्रक्चर परियोजनाओं में उल्लेखनीय विलय का विवरण।

समाचार

  • ● BTCD और LND को प्रभावित करने वाले ब्लॉक पार्सिंग बग: 9 अक्टूबर को, एक उपयोगकर्ता ने Taproot ​​का उपयोग करके एक लेनदेन बनाया जिसमें लगभग एक हजार हस्ताक्षर वाले विटनेस थे। Taproot के लिए सर्वसम्मति नियम विटनेस डेटा के आकार पर कोई सीधी सीमा नहीं रखते हैं। यह एक डिज़ाइन तत्व था जिस पर Taproot के विकास के दौरान चर्चा की गई थी (देखें न्यूज़लेटर #65)।

    बड़े-विटनेस लेनदेन की पुष्टि के तुरंत बाद, उपयोगकर्ताओं ने रिपोर्ट करना शुरू कर दिया कि BTCD पूर्ण नोड कार्यान्वयन और LND Lightning नेटवर्क कार्यान्वयन Bitcoin Core पूर्ण नोड्स के लिए उपलब्ध नवीनतम ब्लॉक से डेटा प्रदान करने में विफल रहे थे। BTCD नोड्स के लिए, इसका मतलब है कि हाल ही में पुष्टि किए गए लेनदेन को अभी भी अपुष्ट बताया जा रहा है। LND के लिए, इसका मतलब था कि जो नए चैनल हाल ही में उपयोग के लिए तैयार हुए थे, उन्हें पूरी तरह से खुला नहीं बताया जा रहा था।

    BTCD और LND दोनों के लिए एक डेवलपर ने BTCD के कोड में समस्या को ठीक किया, जिसे LND एक Library के रूप में उपयोग करता है, और LND दोनों के लिए जल्दी से नए संस्करण जारी किए (जैसा कि पिछले सप्ताह के समाचार पत्र में उल्लेख किया गया है। LND]) और BTCD। BTCD और LND के सभी उपयोगकर्ताओं को अपग्रेड करना चाहिए।

    जब तक कोई उपयोगकर्ता अपने सॉफ़्टवेयर को अपग्रेड नहीं करता है, तब तक उन्हें ऊपर वर्णित पुष्टि की कमी की समस्या का सामना करना पड़ेगा और कई हमलों की चपेट में भी आ सकते हैं। उनमें से कुछ हमलों के लिए महत्वपूर्ण हैश दर तक पहुंच की आवश्यकता होती है (उन्हें महंगा और, उम्मीद है, इस मामले में अव्यवहारिक)। अन्य हमलों, विशेष रूप से LND उपयोगकर्ताओं के खिलाफ, हमलावर को एक चैनल में अपने कुछ फंड खोने का जोखिम उठाने की आवश्यकता होती है, जो उम्मीद है कि एक पर्याप्त निवारक भी है। हम फिर से अपग्रेड की अनुशंसा करते हैं और, आगे, हम अनुशंसा करते हैं कि किसी भी Bitcoin सॉफ़्टवेयर का उपयोग करने वाला कोई भी व्यक्ति उस सॉफ़्टवेयर की विकास टीम से सुरक्षा घोषणाओं के लिए साइन अप करे।

    उपरोक्त खुलासे के बाद, Loki Verloren पोस्ट किया गया Bitcoin-Dev मेलिंग सूची में यह सुझाव देने के लिए कि taproot के विटनेस आकार में सीधी सीमाएं जोड़ दी जाएं। Greg Sanders उत्तर दिया ध्यान दें कि अब सीमाएं जोड़ने से न केवल कोड जटिलता बढ़ेगी बल्कि लोगों को अपना पैसा भी खोना पड़ सकता है यदि उन्हें पहले से ही एक स्क्रिप्ट के लिए Bitcoin प्राप्त हुए हैं जिसके लिए खर्च करने के लिए एक बड़े विटनेस की आवश्यकता होती है।

  • ● लेनदेन प्रतिस्थापन विकल्प: जैसा कि न्यूज़लेटर्स #205 और #208 में रिपोर्ट किया गया है, Bitcoin Core एक mempoolfullrbf कॉन्फ़िगरेशन विकल्प के लिए मर्ज किए गए समर्थन जो मौजूदा Bitcoin Core व्यवहार के लिए डिफ़ॉल्ट है BIP125 सिग्नल वाले लेन-देन के केवल RBF प्रतिस्थापन की अनुमति देना। हालांकि, यदि कोई उपयोगकर्ता नए विकल्प को सही पर सेट करता है, तो उनका नोड लेनदेन के लिए प्रतिस्थापन को स्वीकार करेगा और रिले करेगा जिसमें BIP125 सिग्नल शामिल नहीं है, बशर्ते प्रतिस्थापन लेनदेन प्रतिस्थापन के लिए Bitcoin Core के अन्य नियमों का पालन करें।

    Bitcoin-Dev मेलिंग सूची में Dario Sneidermanis पोस्ट किया गया कि यह नया विकल्प उन सेवाओं के लिए समस्याएं पैदा कर सकता है जो वर्तमान में अपुष्ट लेनदेन को अंतिम रूप में स्वीकार करते हैं। यद्यपि यह वर्षों से उपयोगकर्ताओं के लिए गैर-Bitcoin Core सॉफ़्टवेयर (या Bitcoin Core के पैच किए गए संस्करण) चलाने के लिए संभव है, जो बिना हस्ताक्षर वाले full1 लेनदेन प्रतिस्थापन की अनुमति देता है, इस बात का कोई सबूत नहीं है कि सॉफ़्टवेयर का व्यापक रूप से उपयोग किया जाता है। Sneidermanis का मानना ​​​​है कि Bitcoin Core में एक आसानी से सुलभ विकल्प बदल सकता है, जो पर्याप्त उपयोगकर्ताओं और खनिकों को पूर्ण RBF सक्षम करने और असंकेतित प्रतिस्थापन को विश्वसनीय बनाने की अनुमति देता है। अधिक विश्वसनीय अहस्ताक्षरित प्रतिस्थापन भी उन सेवाओं से चोरी करने के लिए और अधिक विश्वसनीय बना देगा जो अपुष्ट लेनदेन को अंतिम के रूप में स्वीकार करते हैं, उन सेवाओं को उनके व्यवहार को बदलने की आवश्यकता होती है।

    समस्या का वर्णन करने और अपुष्ट लेनदेन को स्वीकार करने के लिए सेवाओं का चयन करने के तरीके का विस्तृत विवरण प्रदान करने के अलावा, Sneidermanis ने एक वैकल्पिक दृष्टिकोण भी प्रस्तावित किया: आगामी Bitcoin Core रिलीज से कॉन्फ़िगरेशन विकल्प को हटा दें, लेकिन कोड भी जोड़ें जो डिफ़ॉल्ट रूप से पूर्ण RBF को सक्षम करेगा। एक भविष्य का क्षण। Anthony Towns पोस्ट किया गया विचार के लिए कई विकल्प हैं और एक पुल अनुरोध खोला है जो Sneidermanis के प्रस्ताव के थोड़ा संशोधित संस्करण को लागू करता है। यदि विलय और अपनी वर्तमान स्थिति में जारी किया जाता है, तो Towns का PR 1 मई 2023 से डिफ़ॉल्ट रूप से पूर्ण RBF को सक्षम कर देगा। पूर्ण RBF पर आपत्ति करने वाले उपयोगकर्ता अभी भी mempoolfullrbf विकल्प को गलत पर सेट करके अपने नोड्स को भाग लेने से रोकने में सक्षम होंगे।

  • ● वैधता रोलअप अनुसंधान: John Light पोस्ट किया गया ​​Bitcoin-Dev मेलिंग सूची के लिए एक विस्तृत शोध रिपोर्ट ​​के लिए एक लिंक उन्होंने वैधता रोलअप के बारे में तैयार किया — एक प्रकार का Sidechain जहां वर्तमान Sidechain स्थिति को Mainchain पर कॉम्पैक्ट रूप से संग्रहीत किया जाता है। Sidechain का एक उपयोगकर्ता यह साबित करने के लिए Mainchain पर संग्रहीत राज्य का उपयोग कर सकता है कि वे कितने Sidechain Bitcoin को नियंत्रित करते हैं। वैधता प्रमाण के साथ एक Mainchain लेनदेन जमा करके, वे अपने स्वयं के Bitcoin को Sidechain से वापस ले सकते हैं, भले ही Sidechain के ऑपरेटर या खनिक निकासी को रोकने की कोशिश करें।

    Light का शोध गहराई से वैधता रोलअप का वर्णन करता है, यह देखता है कि Bitcoin में उनके लिए समर्थन कैसे जोड़ा जा सकता है, और उनके कार्यान्वयन के साथ विभिन्न चिंताओं की जांच करता है।

  • ● MuSig2 सुरक्षा भेद्यता: Jonas Nick पोस्ट किया गया Bitcoin-Dev मेलिंग सूची में एक भेद्यता के बारे में जिसे उन्होंने और कई अन्य लोगों ने MuSig2 एल्गोरिथम में खोजा जैसा कि [ड्राफ्ट BIP] में प्रलेखित है bips #1372। संक्षेप में, प्रोटोकॉल असुरक्षित है यदि कोई हमलावर उपयोगकर्ता की सार्वजनिक कुंजी जानता है, उस सार्वजनिक कुंजी के लिए एक ट्वीक जिसके लिए उपयोगकर्ता हस्ताक्षर करेगा (जैसे कि BIP32 विस्तारित पबकी के साथ), और किस संस्करण में हेरफेर कर सकता है कुंजी जिसके लिए उपयोगकर्ता हस्ताक्षर करेगा।

    Jonas Nick का मानना ​​​​है कि भेद्यता “केवल अपेक्षाकृत दुर्लभ मामलों में ही लागू होनी चाहिए” और किसी को भी (या जल्द ही उपयोग करने की योजना बना रहा है) MuSig2 को उसके और उसके सह-लेखकों तक सवालों के साथ पहुंचने के लिए प्रोत्साहित करता है। MuSig2 के लिए मसौदा BIP को जल्द ही इस मुद्दे को हल करने के लिए अद्यतन किए जाने की उम्मीद है।

  • ● न्यूनतम relayable लेन-देन का आकार: Greg Sanders पोस्ट किया गया Bitcoin-Dev मेलिंग सूची में Bitcoin Core के लिए एक नीति को शिथिल करने के लिए अनुरोध किया गया है ताकि CVE-2017-12842 का फायदा उठाना मुश्किल हो सके। यह भेद्यता एक हमलावर को अनुमति देती है जो एक विशेष रूप से तैयार किए गए 64 Byte लेनदेन को ब्लॉक में पुष्टि कर सकता है ताकि हल्के ग्राहकों को विश्वास हो सके कि एक या अधिक अलग-अलग मनमानी लेनदेन की पुष्टि की गई थी। उदाहरण के लिए, निर्दोष उपयोगकर्ता Bob का सरलीकृत भुगतान सत्यापन (SPV) वॉलेट प्रदर्शित कर सकता है कि उसने दर्जनों पुष्टि के साथ एक मिलियन BTC भुगतान प्राप्त किया था, भले ही इस तरह के भुगतान की कभी पुष्टि नहीं हुई थी।

    जब भेद्यता केवल कुछ डेवलपर्स के बीच निजी तौर पर जानी जाती थी, तो Bitcoin Core में 85 Bytes से कम (विटनेस Bytes की गिनती नहीं) के साथ किसी भी लेनदेन के रिले को रोकने के लिए एक सीमा जोड़ दी गई थी, जो कि सबसे छोटे आकार के बारे में है जिसे मानक लेनदेन टेम्पलेट्स का उपयोग करके बनाया जा सकता है . इसके लिए एक हमलावर को अपने लेनदेन को Bitcoin Core पर आधारित सॉफ़्टवेयर द्वारा खनन करने की आवश्यकता होगी। बाद में, आम सहमति सफाई सॉफ्ट फोर्क प्रस्ताव ने 65 Bytes से कम आकार के किसी भी लेनदेन को नए ब्लॉक में शामिल करने से रोककर समस्या को स्थायी रूप से ठीक करने का सुझाव दिया।

    Sanders का सुझाव है कि सर्वसम्मति की सफाई में सुझाई गई लेन-देन रिले नीति की सीमा को 85 Bytes से घटाकर 65 Byte की सीमा तक किया जाए, जो वर्तमान जोखिम प्रोफ़ाइल को बदले बिना अतिरिक्त प्रयोग और उपयोग की अनुमति दे सकता है। इस परिवर्तन को करने के लिए Sanders के पास पुल अनुरोध खुला है। इस प्रस्तावित परिवर्तन से संबंधित पूर्व चर्चा के लिए न्यूज़लेटर #99 भी देखें।

  • ● BIP324 अपडेट: Bitcoin-Dev मेलिंग सूची में Dhruv एम पोस्ट किया गयाversion 2 encrypted p2p transport protocol के लिए BIP 324 प्रस्ताव के कई अपडेट का सारांश। इसमें मसौदा BIP का पुनर्लेखन और संसाधनों की विविधता का प्रकाशन शामिल है ताकि समीक्षकों को प्रस्ताव का मूल्यांकन करने में मदद मिल सके, जिसमें एक उत्कृष्ट प्रस्तावित कोड परिवर्तन के लिए गाइड शामिल है। कई भंडारों में परिवर्तन]।

    जैसा कि BIP के प्रेरणा खंड के मसौदे में वर्णित है, Bitcoin नोड्स के लिए एक देशी encrypted transport protocol लेनदेन की घोषणा के दौरान गोपनीयता में सुधार कर सकता है, कनेक्शन के साथ छेड़छाड़ को रोक सकता है (या कम से कम छेड़छाड़ का पता लगाना आसान बना सकता है), और P2P कनेक्शन सेंसरशिप भी बना सकता है और [ eclipse हमलो को [topic eclipse के हमले] अधिक कठिन।

सेवाओं और क्लाइंट सॉफ़्टवेयर में परिवर्तन

इस मासिक फीचर में, हम Bitcoin वॉलेट और सेवाओं के दिलचस्प अपडेट को हाईलाइट करते हैं।

  • ● BTCD v0.23.2 जारी किया गया: btcd v0.23.2 (और v0.23.1) addr v2 और PSBTs के लिए अतिरिक्त समर्थन जोड़ता है, Taproot, और MuSig 2 के साथ-साथ अन्य संवर्द्धन और सुधार।

  • ● ZEBEDEE ने होस्टेड चैनल लाइब्रेरी की घोषणा की: हाल ही में ब्लॉग पोस्ट में, ZEBEDEE ने एक ओपन सोर्स वॉलेट (ओपन Bitcoin वॉलेट), Core Lightning plugin (Poncho), Lightning क्लाइंट (Cliché) और Lightning की घोषणा की। Library (Immortan) जो [होस्ट किए गए चैनलों] के समर्थन पर ध्यान केंद्रित करता है।

  • ● Cashu Lightning सपोर्ट के साथ लॉन्च हुआ: ई-कैश Software Cashu Lightning के समर्थन के साथ प्रूफ-ऑफ-कॉन्सेप्ट वॉलेट के रूप में लॉन्च हुआ।

  • ● एड्रेस एक्सप्लोरर Spiral लॉन्च: Spiral एक खुला स्रोत सार्वजनिक पता एक्सप्लोरर है जो किसी पते के बारे में जानकारी पूछने वाले उपयोगकर्ताओं को गोपनीयता प्रदान करने के लिए क्रिप्टोग्राफी का उपयोग करता है।

  • ● BitGo ने Lightning सपोर्ट की घोषणा की: एक ब्लॉग पोस्ट में, BitGo अपनी कस्टोडियल Lightning सेवा का वर्णन करता है जो अपने ग्राहकों की ओर से नोड्स चलाता है और भुगतान चैनल तरलता बनाए रखता है।

  • ● ZeroSync प्रोजेक्ट लॉन्च: ZeroSync प्रोजेक्ट Bitcoin नोड को Sync करने के लिए Utreexo और STARK प्रूफ का उपयोग कर रहा है, जैसा कि इनिशियल ब्लॉक डाउनलोड (IBD) में होता है।

रिलीज और रिलीज उम्मीदवार

लोकप्रिय Bitcoin इन्फ्रास्ट्रक्चर परियोजनाओं के लिए नए रिलीज और रिलीज उम्मीदवार। कृपया नई रिलीज़ में अपग्रेड करने या रिलीज़ उम्मीदवारों का परीक्षण करने में मदद करने पर विचार करें।

  • ● Bitcoin Core 24.0 RC2 नेटवर्क के सबसे व्यापक रूप से उपयोग किए जाने वाले पूर्ण नोड कार्यान्वयन के अगले संस्करण के लिए एक रिलीज उम्मीदवार है। एक गाइड टू टेस्टिंग उपलब्ध है।

  • ● LND 0.15.3-beta एक छोटी रिलीज है जो कई बगों को ठीक करती है।

उल्लेखनीय कोड और दस्तावेज़ीकरण परिवर्तन

इस सप्ताह Bitcoin Core, Core Lightning, Eclair, LDK, LND में उल्लेखनीय परिवर्तन। libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIP), और Lightning BOLTs।

  • ● Bitcoin Core #23549 स्कैनब्लॉक्स RPC को जोड़ता है जो डिस्क्रिप्टर के दिए गए सेट के लिए दी गई सीमा में प्रासंगिक ब्लॉक की पहचान करता है। RPC केवल उन नोड्स पर उपलब्ध है जो कॉम्पैक्ट ब्लॉक फ़िल्टर इंडेक्स (-blockfilterindex=1) बनाए रखते हैं।

  • ● Bitcoin Core #25412 एक नया /deploymentinfo REST एंडपॉइंट जोड़ता है जिसमें मौजूदा getdeploymentinfo RPC के समान सॉफ्ट फोर्क परिनियोजन के बारे में जानकारी होती है।

  • ● LND #6956 चैनल के पार्टनर से प्राप्त भुगतानों पर लागू किए गए न्यूनतम चैनल रिजर्व को कॉन्फ़िगर करने की अनुमति देता है। एक नोड अपने चैनल पार्टनर से भुगतान स्वीकार नहीं करेगा यदि इससे चैनल में पार्टनर के फंड की राशि रिजर्व से कम हो जाती है, जो कि LND में डिफ़ॉल्ट रूप से 1% है। यह सुनिश्चित करता है कि यदि पार्टनर किसी चैनल को पुरानी स्थिति में बंद करने का प्रयास करता है तो उसे दंड के रूप में कम से कम आरक्षित राशि का भुगतान करना होगा। यह विलय PR आरक्षित राशि को कम करने या बढ़ाने की अनुमति देता है।

  • ● LND #7004 LND द्वारा उपयोग किए गए BTCD लाइब्रेरी के संस्करण को अपडेट करता है, इस न्यूजलेटर में पहले वर्णित सुरक्षा भेद्यता को ठीक करता है।

  • ● LDK #1625 दूर के चैनलों की तरलता के बारे में जानकारी ट्रैक करना शुरू करता है, जिसके माध्यम से स्थानीय नोड ने भुगतान को रूट करने का प्रयास किया है। स्थानीय नोड उन भुगतानों के आकार के बारे में जानकारी संग्रहीत करता है जो या तो दूरस्थ नोड के माध्यम से सफलतापूर्वक रूट किए गए हैं या जो स्पष्ट रूप से अपर्याप्त धन के कारण विफल हो गए हैं। यह जानकारी, इसकी उम्र के लिए समायोजित, संभाव्य पथ-खोज के लिए इनपुट के रूप में उपयोग की जाती है (देखें न्यूज़लेटर #163)।

फुटनोट

  1. Bitcoin के पहले संस्करण में लेनदेन प्रतिस्थापन शामिल किया गया था और पिछले कुछ वर्षों में बहुत चर्चा हुई है। उस समय के दौरान, इसके पहलुओं का वर्णन करने के लिए उपयोग किए जाने वाले कई शब्द बदल गए हैं, जिससे संभावित भ्रम पैदा हो गया है। शायद भ्रम का सबसे बड़ा स्रोत “full RBF” शब्द होगा, जिसका इस्तेमाल दो अलग-अलग अवधारणाओं के लिए किया गया है:

    • ● किसी लेन-देन के किसी भी भाग का पूर्ण प्रतिस्थापन केवल अतिरिक्त इनपुट और आउटपुट जोड़ने से अलग। उस अवधि के दौरान जब RBF को सक्षम करना विवादास्पद था और RBF में ऑप्ट-इन करने के विचार के प्रस्तावित होने से पहले, एक सुझाव लेनदेन को केवल तभी बदलने की अनुमति देना था जब प्रतिस्थापन में सभी समान आउटपुट और अतिरिक्त नए इनपुट शामिल हों और आउटपुट शुल्क का भुगतान करने और परिवर्तन एकत्र करने के लिए उपयोग किए जाते हैं। मूल आउटपुट को रखने की आवश्यकता सुनिश्चित करती है कि प्रतिस्थापन अभी भी मूल रिसीवर को उतनी ही राशि का भुगतान करेगा। यह विचार, जिसे बाद में First Seen Safe (FSS) RBF कहा गया, एक प्रकार का आंशिक प्रतिस्थापन था।

      तुलना करके, इस समय full प्रतिस्थापन का मतलब था कि प्रतिस्थापन मूल लेनदेन के बारे में पूरी तरह से कुछ भी बदल सकता है (बशर्ते यह अभी भी एक ही इनपुट में से कम से कम एक खर्च करके मूल लेनदेन के साथ विवादित हो)। यह पूर्ण का उपयोग है जिसका उपयोग BIP125, “Opt-in Full Replace-by-Fee Signaling” के शीर्षक में किया गया है।

    • ● किसी भी लेन-देन का पूर्ण प्रतिस्थापन केवल उन लेन-देन को बदलने से अलग है जो BIP125 सिग्नल के माध्यम से प्रतिस्थापन की अनुमति देने के लिए ऑप्ट-इन करते हैं। ऑप्ट-इन RBF को उन लोगों के बीच एक समझौते के रूप में प्रस्तावित किया गया था जो RBF को अनुमति नहीं देना चाहते थे और जो मानते थे कि यह आवश्यक या अपरिहार्य था। हालांकि, इस लेखन के रूप में, केवल कुछ ही लेन-देन RBF में ऑप्ट-इन करते हैं, जिसे RBF के आंशिक रूप से अपनाने के रूप में देखा जा सकता है।

      तुलना करके, किसी भी अपुष्ट लेनदेन को बदलने की अनुमति देकर RBF को full अपनाने को सक्षम बनाया जा सकता है। यह पूर्ण का यह उपयोग है जो वर्तमान में चर्चित Bitcoin Core कॉन्फ़िगरेशन विकल्प, mempoolfullrbf में उपयोग किया जाता है।

    ↩