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

समाचार

• ● शुल्क द्वारा पूर्ण प्रतिस्थापन: दो पुल अनुरोध को Bitcoin Core में पूर्ण प्रतिस्थापन शुल्क के लिए समर्थन जोड़ने के लिए खोला गया है (RBF) एक विकल्प के रूप में जो डिफ़ॉल्ट रूप से बंद है। यदि सक्षम किया गया है, तो उस नोड के mempool में किसी भी अपुष्ट लेनदेन को उस लेनदेन के वैकल्पिक संस्करण से बदला जा सकता है जो उच्च शुल्क का भुगतान करता है (अन्य नियमों के बीच)।

  वर्तमान में Bitcoin Core केवल RBF की अनुमति देता है यदि लेन-देन के संस्करण को बदलने के लिए एक सिग्नलिंग बिट सक्षम है, जैसा कि BIP125 में परिभाषित किया गया है। यह एलएन और DLC जैसे बहुपक्षीय अनुबंध प्रोटोकॉल के लिए एक चुनौती पैदा करता है, जहां कभी-कभी एक पक्ष के लिए लेनदेन से BIP125 सिग्नल को हटाना संभव होता है ताकि अन्य पार्टियों को लेनदेन प्रतिस्थापन का उपयोग करने से रोका जा सके। इससे देरी हो सकती है, और सबसे खराब स्थिति में यह प्रोटोकॉल में धन की हानि का कारण बन सकता है जो समय पर पुष्टि पर निर्भर करता है (जैसे कि HTLCs के लिए)।

  PRs में से एक को जल्दी से महत्वपूर्ण डेवलपर समर्थन प्राप्त हुआ। क्योंकि यह केवल पूर्ण RBF को सक्षम करने की क्षमता जोड़ता है — लेकिन इसे डिफ़ॉल्ट रूप से सक्षम नहीं करता — यह Bitcoin Core के वर्तमान डिफ़ॉल्ट व्यवहार को नहीं बदलता है। लंबी अवधि में, कुछ डेवलपर्स डिफ़ॉल्ट रूप से पूर्ण RBF को सक्षम करने की वकालत करेंगे, इसलिए सेवाओं, अनुप्रयोगों और वैकल्पिक पूर्ण नोड के डेवलपर्स को देने के लिए इस सप्ताह Bitcoin-Dev मेलिंग सूची पर एक धागा शुरू किया गया था। सॉफ्टवेयर को एक पूर्ण RBF विकल्प प्रदान करने की दिशा के खिलाफ बहस करने का मौका देता है और शायद अंततः इसे डिफ़ॉल्ट रूप से सक्षम करता है।

• ● Hertzbleed: हाल ही में खुलासा कई (शायद सभी) लोकप्रिय लैपटॉप, डेस्कटॉप और सर्वर सीपीयू प्रोसेसर को प्रभावित करने वाली सुरक्षा भेद्यता हमलावरों को निजी कुंजी खोजने की अनुमति दे सकती है जब उन कुंजियों का उपयोग Bitcoin के लिए हस्ताक्षर बनाने के लिए किया जा रहा हो। लेनदेन (या अन्य समान संचालन करें)। इस हमले का उल्लेखनीय पहलू यह है कि यह हस्ताक्षर पीढ़ी कोड को प्रभावित कर सकता है जो विशेष रूप से हमलावरों को जानकारी लीक होने से रोकने के लिए हमेशा एक ही प्रकार और सीपीयू संचालन की संख्या का उपयोग करने के लिए लिखा गया था।

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

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

• ● टाइमस्टैम्पिंग डिज़ाइन: Bitcoin-आधारित Open Timestamps (OTS) सिस्टम के डिज़ाइन के बारे में Bitcoin-Dev मेलिंग सूची पर एक लंबी बहस इस सप्ताह समापन लग रही थी। ऐसा प्रतीत होता है कि बहस का स्रोत टाइम स्टैम्पिंग सिस्टम के लिए दो अलग-अलग डिज़ाइनों का अस्तित्व रहा है:

  • ● टाइम स्टैम्प्ड प्रूफ ऑफ एक्सिस्टेंस (TSPoE): एक Bitcoin लेनदेन एक हैश डाइजेस्ट के लिए प्रतिबद्ध है जो एक दस्तावेज़ के लिए प्रतिबद्ध है। जब किसी ब्लॉक में लेन-देन की पुष्टि हो जाती है, तो प्रतिबद्धता के निर्माता के लिए तीसरे पक्ष को यह साबित करना संभव है कि दस्तावेज़ उस समय मौजूद था जब ब्लॉक बनाया गया था। विशेष रूप से, हर बार स्टैम्पिंग ट्रांजैक्शन अन्य टाइम स्टैम्पिंग ट्रांजैक्शन से पूरी तरह से स्वतंत्र हो सकता है, जिसका अर्थ है कि टाइम स्टैम्प के बीच कोई संबंध नहीं होने पर एक ही दस्तावेज़ को कई बार टाइमस्टैम्प करना संभव है।

  • ● इवेंट ऑर्डरिंग (EO): एक निर्दिष्ट तरीके से एक-दूसरे से संबंधित सभी लेन-देन की एक श्रृंखला इस तरह से दस्तावेजों के लिए प्रतिबद्ध है कि सिस्टम के किसी भी उपयोगकर्ता को सभी प्रतिबद्धताओं को देखने की अनुमति मिलती है। इस प्रणाली के तहत दो या अधिक बार टाइमस्टैम्प किए गए किसी भी दस्तावेज़ के लिए, यह निर्धारित करना संभव है कि यह पहली बार टाइमस्टैम्प किया गया था।

  OTS द्वारा कार्यान्वित टीएसपीओई प्रणाली अनिवार्य रूप से पूरी तरह से कुशल है। यह समय-समय पर असीमित संख्या में दस्तावेजों पर मुहर लगाने के लिए वैश्विक भंडारण स्थान की समान मात्रा का उपयोग करता है, प्रत्येक व्यक्ति जो टाइमस्टैम्प का अनुरोध करता है, वह अपने टाइम स्टैम्प प्रूफ को संग्रहीत करने के लिए जिम्मेदार होता है। इस प्रणाली को अवधारणा और कार्यान्वयन दोनों में सरल होने का भी फायदा है।

  EO प्रणाली के लिए आवश्यक है कि सभी पूर्ण प्रतिभागी प्रत्येक दस्तावेज़ के प्रति प्रतिबद्धताओं को संग्रहित करें। यह बहुत कम कुशल हो सकता है और जटिलता जोड़ता है। ट्रेडऑफ़ यह है कि यह प्रतिभागियों को यह सत्यापित करने की अनुमति देता है कि सिस्टम में पहली बार दस्तावेज़ कब प्रकाशित किया गया था।

  चर्चा ने किसी भी प्रणाली या प्रस्ताव में किसी भी घोषित परिवर्तन का नेतृत्व नहीं किया, जैसे कि ओपन टाइमस्टैम्प या लेनदेन प्रायोजन (चर्चा का मूल विषय, न्यूज़लेटर #116 देखें)। यह कई चर्चा प्रतिभागियों को आश्चर्यचकित करने वाला प्रतीत होता है कि उनमें से प्रत्येक की अलग-अलग अवधारणाएं हो सकती हैं कि “टाइम स्टैम्पिंग” का क्या अर्थ है।

• ● नई RIDDLE एंटी-Sybil विधि: Adam “Waxwing” Gibson पोस्ट किया गया Bitcoin-Dev मेलिंग सूची में एंटी-Sybil के लिए एक प्रस्ताव तंत्र जो Bitcoin UTXO सेट का उपयोग करता है और जो उचित रूप से अच्छी गोपनीयता प्रदान कर सकता है। एक उपयोगकर्ता UTXO की एक सूची तैयार कर सकता है जहां UTXO में से एक उपयोगकर्ता से संबंधित है और शेष अन्य उपयोगकर्ताओं से संबंधित है। उपयोगकर्ता तब एक हस्ताक्षर बनाता है जो सूचीबद्ध UTXO में से एक के मालिक से आया है, लेकिन यह नहीं बताता है कि इसे किस मालिक ने बनाया है।

  एक दुर्भावनापूर्ण उपयोगकर्ता ऐसे कई सबूत उत्पन्न कर सकता है, लेकिन विकल्पों के पूल को समाप्त करने से पहले उनमें से केवल एक सीमित संख्या में, दुर्लभ नेटवर्क संसाधनों को खत्म करने की उनकी क्षमता को सीमित कर सकता है। दुर्भावनापूर्ण उपयोगकर्ता यथासंभव लंबे समय तक UTXO का उपयोग कर सकते हैं और फिर इसे एक नया UTXO प्राप्त करने के लिए खर्च कर सकते हैं, लेकिन इसके लिए एक लेनदेन शुल्क लगेगा। वह महँगाई भी दुरुपयोग को रोकती है। उपयोगकर्ता द्वारा चुने जाने वाले UTXO को सीमित करके सेवाएँ Sybil को और सीमित कर सकती हैं। उदाहरण के लिए, एक सेवा केवल UTXO पर एक हस्ताक्षर स्वीकार कर सकती है जो मूल्य में 1 बीटीसी है और जो एक वर्ष के लिए खर्च नहीं किया गया है।

  Gibson का प्रस्ताव है कि सदस्यता प्रमाण दो रूपों में आ सकते हैं। एक वैश्विक प्रमाण और एक स्थानीय प्रमाण। वैश्विक प्रमाणों को सत्यापनकर्ताओं के बीच साझा किया जाएगा ताकि, आदर्श परिस्थितियों में, एक उपयोगकर्ता वैश्विक संदर्भ में प्रति UTXO केवल एक प्रमाण बना सके। उदाहरण के लिए, उपयोगकर्ता प्रत्येक वर्ष पुराने UTXO के लिए 1 BTC मूल्य के केवल एक खाते के लिए साइन अप करने में सक्षम होगा।

  स्थानीय संदर्भ एकल सत्यापनकर्ता (या संबद्ध सत्यापनकर्ताओं का एक समूह, जैसे विकेन्द्रीकृत विनिमय पर) के लिए विशिष्ट होंगे। उदाहरण के लिए, एक उपयोगकर्ता सेवा A पर API तक पहुंचने के लिए UTXO का उपयोग कर सकता है और फिर सेवा B के लिए उसी UTXO का पुन: उपयोग कर सकता है।

  इसके अतिरिक्त, उच्च मूल्य वाले UTXO को कम मूल्य के कई UTXO के रूप में माना जा सकता है, इसलिए एक 10 BTC UTXO उपयोगकर्ता को विभिन्न सेवाओं में 10 अलग-अलग खातों के लिए साइन अप करने की अनुमति दे सकता है, जिनमें से प्रत्येक को वैश्विक संदर्भ में 1 BTC पूंजी की आवश्यकता होती है।

  यद्यपि RIDDLE प्रोटोकॉल अन्य एंटी-Sybil तंत्रों पर गोपनीयता लाभ प्रदान करता है, Gibson चेतावनी देता है कि सिस्टम के उपयोग की जानकारी को उपयोगकर्ता की गोपनीयता को संभावित रूप से कम करने के लिए अन्य उपलब्ध जानकारी के साथ जोड़ा जा सकता है। वे लिखते हैं, “इस बात की कोई संभावना नहीं है कि इस तरह की प्रणाली पक्की गोपनीयता की गारंटी प्रदान कर सकती है। यदि वास्तविक हस्ताक्षर करने वाले यूटक्सो के स्थान की रक्षा करना जीवन और मृत्यु का मामला है, तो किसी भी तरह से इस तरह की प्रणाली का उपयोग न करें!”

  Lightning-Dev मेलिंग सूची में, डेवलपर ZmnSCPxj सुझाया गया RIDDLE, LN के एंटी-Sybil तंत्र को UTXO-आधारित चैनल पहचानकर्ताओं से अलग करने का एक विकल्प हो सकता है, जो टैपरोट और [टैपरोट] के युग में है। हस्ताक्षर एकत्रीकरण [विषय संगीत], अनावश्यक रूप से खुलासा करें कि कौन से ऑन-चेन लेनदेन एलएन चैनल खोलता है और आपसी बंद होता है।

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

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

• ● Zeus Taproot सपोर्ट जोड़ता है: Zeus v0.6.5-rc1 Taproot ​​जोड़ता है और LND v0.15+ बैकएंड के लिए समर्थन भेजता है।

• ● Wasabi Wallet 2.0 जारी: यह CoinJoin सॉफ्टवेयर रिलीज अन्य सुधारों के साथ WabiSabi प्रोटोकॉल को लागू करता है।

• ● Sparrow Taproot हार्डवेयर साइनिंग जोड़ता है: HWI 2.1.0 में अपग्रेड करके, Sparrow 1.6.4 कुछ हार्डवेयर साइनिंग डिवाइस के लिए Taproot साइनिंग सपोर्ट जोड़ता है।

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

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

• ● LND 0.15.0-beta.rc6 इस लोकप्रिय LN नोड के अगले प्रमुख संस्करण के लिए रिलीज़ उम्मीदवार है।

• ● LDK 0.0.108 और 0.0.107 ऐसे रिलीज़ हैं जो मोबाइल की अनुमति देने वाले कोड प्रदान करने के अलावा बड़े चैनल और शून्य-कॉन्फ़ चैनल के लिए समर्थन जोड़ते हैं। क्लाइंट एक सर्वर से नेटवर्क रूटिंग जानकारी (gossip), साथ ही अन्य सुविधाओं और बग फिक्स को सिंक करने के लिए।

• ● BDK 0.19.0 Taproot ​​के लिए डिस्क्रिप्टर, पीएसबीटी, और अन्य उप-प्रणालियों के माध्यम से प्रयोगात्मक समर्थन जोड़ता है। यह एक नया सिक्का चयन एल्गोरिथ्म भी जोड़ता है।

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

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

• ● Bitcoin Core GUI #602 GUI में बदली गई सेटिंग्स को हेडलेस daemon (bitcoind) द्वारा लोड की गई फाइल में लिखता है, इसलिए बदली गई सेटिंग्स का उपयोग किया जाता है, इससे कोई फर्क नहीं पड़ता कि उपयोगकर्ता Bitcoin Core कैसे शुरू करता है।

• ● Eclair #2224 Short Channel Identifier (scid) उपनाम और ज़ीरो-कॉन्फ़ चैनल प्रकार का समर्थन जोड़ता है। scid उपनाम गोपनीयता में सुधार कर सकते हैं और पर्याप्त पुष्टि होने से पहले नोड्स के लिए चैनल को आसानी से संदर्भित करना संभव बनाते हैं। ज़ीरो-कॉन्फ़ चैनल दो नोड्स को पर्याप्त रूप से पुष्टि होने से पहले भुगतान को रूट करने के लिए एक चैनल का उपयोग करने के लिए सहमत होने की अनुमति देता है, जो कुछ प्रतिबंधों के तहत सुरक्षित हो सकता है।

• ● HWI #611 BitBox02 हार्डवेयर साइनिंग डिवाइस के साथ bech32m पतों के लिए सिंगल-सिग सपोर्ट जोड़ता है।