इस सप्ताह का न्यूज़लेटर schnorr हस्ताक्षरों के आधे एकत्रीकरण के बारे में चर्चाओं को सारांशित करता है, प्रोटोकॉल के लिए एक समाधान जो मज़बूती से x-only pubkeys का उपयोग नहीं कर सकता है, और जानबूझकर धीमी LN भुगतान अग्रेषण की अनुमति देता है। Bitcoin Core PR Review Club के सारांश के साथ हमारे नियमित खंड भी शामिल हैं, रिलीज और रिलीज उम्मीदवारों की घोषणाएं, और लोकप्रिय Bitcoin इंफ्रास्ट्रक्चर परियोजनाओं में उल्लेखनीय परिवर्तनों के विवरण शामिल हैं।

समाचार

• ● BIP340 हस्ताक्षरों का आधा एकत्रीकरण: Jonas Nick पोस्ट किया गया Bitcoin-Dev मेलिंग सूची में ड्राफ्ट BIP और ब्लॉग पोस्ट लगभग आधा एकत्रीकरण Bitcoin schnorr हस्ताक्षर। जैसा कि ब्लॉग पोस्ट में उल्लेख किया गया है, प्रस्ताव “एक से अधिक schnorr हस्ताक्षरों को एक एकल हस्ताक्षर में एकत्र करने की अनुमति देता है जो कि व्यक्तिगत हस्ताक्षरों के योग से लगभग आधा है। महत्वपूर्ण रूप से, यह योजना गैर-संवादात्मक है, जिसका अर्थ है कि हस्ताक्षरों का एक सेट कर सकते हैं हस्ताक्षरकर्ताओं की भागीदारी के बिना किसी तीसरे पक्ष द्वारा आधा-एकत्रित किया जाना चाहिए।”

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

• ● X-only वर्कअराउंड: Bitcoin सार्वजनिक कुंजियाँ द्वि-आयामी ग्राफ़ पर बिंदु हैं जो एक x निर्देशांक और एक y निर्देशांक के प्रतिच्छेदन द्वारा संदर्भित होते हैं। किसी दिए गए x निर्देशांक के लिए, केवल दो मान्य y निर्देशांक हैं और इनकी गणना x मान से की जा सकती है। इसने [Taproot]​​topic Taproot ​​के डिजाइन में एक अनुकूलन की अनुमति दी, जिसमें BIP340 के साथ उपयोग की जाने वाली सभी सार्वजनिक कुंजी की आवश्यकता होती है BIP340-स्टाइल Schnorr हस्ताक्षर केवल इनमें से एक निश्चित y निर्देशांक का उपयोग करने के लिए, किसी भी सार्वजनिक कुंजी को शामिल करने की इजाजत देता है लेन-देन को पूरी तरह से y बिंदु सहित छोड़ने के लिए, मूल Taproot डिज़ाइन पर प्रति हस्ताक्षर एक vbyte की बचत करना।

  उस समय, इस तकनीक (जिसे x-only public key कहा जाता है) को कोई महत्वपूर्ण ट्रेडऑफ़ के साथ एक अनुकूलन माना जाता था, लेकिन बाद में OP_TAPLEAF_UPDATE_VERIFY (TLUV) पर डिज़ाइन कार्य से पता चला कि x-only pubkeys की या तो आवश्यकता थी कम्प्यूटेशनल रूप से प्रस्ताव को सीमित करना या ब्लॉक श्रृंखला या UTXO सेट में अतिरिक्त डेटा संग्रहीत करना। समस्या pubkey के अन्य उन्नत उपयोगों को भी प्रभावित कर सकती है।

  इस हफ्ते, Bitcoin-Dev मेलिंग सूची में Tim Ruffing पोस्ट किया गया एक संभावित समाधान है जिसके लिए केवल हस्ताक्षरकर्ताओं द्वारा अतिरिक्त गणना की थोड़ी सी आवश्यकता होती है—एक राशि जो संसाधन-विवश हार्डवेयर हस्ताक्षर करने वाला उपकरण भी शायद प्रदर्शन कर सकता है अपने उपयोगकर्ता को बहुत लंबा इंतजार किए बिना।

• ● जानबूझकर धीमी LN भुगतान अग्रेषण की अनुमति देना: पुनरावर्ती/नेस्टेड MuSig2 के बारे में एक थ्रेड के उत्तर में (देखें न्यूज़लेटर #204) और विलंबता जो इसका उपयोग करने वाले नोड्स को जोड़ देगा भुगतानों को रूट करते समय, डेवलपर Peter Todd ने Lightning-Dev मेलिंग सूची पर पूछें कि क्या यह “लोगों को गोपनीयता के लिए अधिक धीरे-धीरे होने वाले अपने भुगतानों में ऑप्ट-इन करने की अनुमति देने के लिए उपयुक्त होगा?” उदाहरण के लिए, यदि Alice और Bob प्रत्येक ने कैरल के फ़ॉरवर्डिंग नोड के माध्यम से Dan के फ़ॉरवर्डिंग नोड को एक ही समय के आसपास अग्रेषित-धीरे-धीरे भुगतान भेजा, तो कैरल दोनों भुगतानों को एक साथ अग्रेषित करने में सक्षम होगी, प्रतिभागियों के बारे में गोपनीयता-लीक जानकारी की मात्रा को कम कर सकती है कि तीसरे पक्ष संतुलन जांच, नेटवर्क गतिविधि निगरानी, ​​या अन्य तकनीकों के माध्यम से खोज सकता है। डेवलपर मैट Coreलो सहमत यह एक दिलचस्प विचार था।

Bitcoin Core PR Review Club

इस मासिक खंड में, हम हाल ही में एक Bitcoin Core PR Review Club बैठक का सारांश प्रस्तुत करते हैं, जिसमें कुछ महत्वपूर्ण प्रश्नों और उत्तरों पर प्रकाश डाला गया है। मीटिंग के उत्तर का सारांश देखने के लिए नीचे दिए गए प्रश्न पर क्लिक करें।

Manual block-relay-only connections with addnode Martin Zumsande द्वारा एक PR है जो उपयोगकर्ताओं को मैन्युअल रूप से नोड्स के साथ कनेक्शन बनाने की अनुमति देता है, जिस पर केवल ब्लॉक (लेनदेन या सहकर्मी पते नहीं) रिले किए जाते हैं। इस विकल्प का उद्देश्य eclipse हमलों को रोकने में मदद करना है, विशेष रूप से गोपनीयता नेटवर्क जैसे Tor पर चलने वाले नोड्स के लिए।

• केवल Tor जैसे गोपनीयता नेटवर्क पर सक्रिय सहकर्मी केवल-क्लीयरनेट साथियों की तुलना में eclipse के हमलों के प्रति अधिक संवेदनशील क्यों हो सकते हैं?

  Clearnet पर नोड्स ‘विविध’ साथियों को चुनने का प्रयास करने के लिए IP पतों के नेटवर्क समूहों जैसी जानकारी का उपयोग कर सकते हैं। दूसरी ओर, यह बताना मुश्किल है कि क्या onion का एक सेट सभी एक ही हमलावर से संबंधित है, इसलिए यह कठिन है Tor पर ऐसा करने के लिए। इसके अलावा, जबकि Tor पर चल रहे Bitcoin नोड्स का सेट काफी बड़ा है, कुछ Bitcoin नोड्स वाले गोपनीयता नेटवर्क पर -onlynet का उपयोग करने वाले नोड को आसानी से eclipse किया जा सकता है, क्योंकि साथियों के लिए कई विकल्प नहीं हैं। ➚

• addnode RPC में onetry और add मोड में क्या अंतर है?

  जैसा कि नाम से पता चलता है, onetry केवल CConnman::OpenNetworkConnection() को एक बार कॉल करने का प्रयास करता है। यदि यह विफल हो जाता है, तो पीयर नहीं जोड़ा जाता है। दूसरी ओर, एडनोड मोड नोड को बार-बार प्रयास करने का कारण बनता है सफल होने तक नोड से कनेक्ट करने के लिए। ➚

• PR एक नया कनेक्शन प्रकार पेश करता है MANUAL_BLOCK_RELAY जो MANUAL और BLOCK_RELAY साथियों के गुणों को जोड़ता है। मौजूदा कनेक्शन के तर्क के संयोजन के विपरीत, एक अतिरिक्त कनेक्शन प्रकार होने के फायदे और नुकसान क्या हैं ?

  चूंकि P2P कनेक्शन के कई गुण हैं लेकिन कुछ प्रकार हैं, प्रतिभागियों ने सहमति व्यक्त की कि फ्लैट, एन्यूमरेटेड कनेक्शन प्रकारों का उपयोग करना सरल है। उन्होंने यह भी नोट किया कि क्षमताओं और अनुमतियों के संयोजन का उपयोग करके कनेक्शन का वर्णन करने से कनेक्शन प्रकारों का एक संयोजनीय विस्फोट हो सकता है और जटिल हो सकता है। तर्क, जिसमें कुछ ऐसे भी शामिल हैं जिनका कोई मतलब नहीं हो सकता है। ➚

• किस प्रकार के हमले जिन्हें यह PR कम करने का प्रयास करता है, BIP324 द्वारा तय किए गए हैं? कौन से नहीं हैं?

  BIP324 ईव्सड्रॉपिंग और नेटवर्क-व्यापी निगरानी को रोकने के लिए अवसरवादी एन्क्रिप्शन जोड़कर गोपनीयता को बढ़ाता है, लेकिन eclipse के हमलों को रोकने का इरादा नहीं है। यहां तक ​​​​कि प्रमाणीकरण के कुछ तंत्र के साथ, यह यह पहचानने में मदद नहीं करता है कि सहकर्मी ईमानदार है या नहीं या अन्य साथियों से एक अलग इकाई। ➚

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

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

• ● BTCPay Server 1.6.1 इस लोकप्रिय स्व-होस्टेड भुगतान प्रोसेसर समाधान की 1.6 शाखा की रिलीज है जिसमें कई नई सुविधाएं और बग फिक्स शामिल हैं।

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

इस सप्ताह 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 #25353 पहले न्यूज़लेटर #205 में वर्णित mempoolfullrbf कॉन्फ़िगरेशन विकल्प पेश करता है। यह विकल्प नोड ऑपरेटरों को अपने नोड के लेनदेन प्रतिस्थापन व्यवहार को डिफ़ॉल्ट ऑप्ट-इन RBF (BIP125) से पूर्ण RBF में स्विच करने में सक्षम बनाता है-सिग्नलिंग आवश्यकता को लागू किए बिना नोड के mempool में लेनदेन प्रतिस्थापन की अनुमति देता है, लेकिन RBF में ऑप्ट-इन के समान आर्थिक नियमों का पालन करना।

• ● Bitcoin Core #25454 एक ही सहकर्मी के लिए उड़ान में कई getheaders संदेशों से बचा जाता है, जो एक नया जारी करने से पहले एक पूर्व getheaders संदेश की प्रतिक्रिया के लिए दो मिनट तक प्रतीक्षा करके बैंडविड्थ उपयोग को कम करता है।

• ● Core Lightning #5239 सभी प्राप्त घोषणाओं का उपयोग करते हुए भुगतान रिले नेटवर्क के CLN के आंतरिक मानचित्र को अपडेट करके गॉसिप हैंडलिंग कोड में सुधार करता है, लेकिन केवल उन घोषणाओं को रिले करना जारी रखता है जो CLN की गपशप दर सीमाओं को पूरा करती हैं। पहले, CLN ने अपनी दर सीमा के अनुसार आने वाले संदेशों को हटा दिया था। परिवर्तन CLN नोड्स को नेटवर्क का एक बेहतर दृश्य दे सकता है जब उनके साथियों के पास CLN द्वारा अपने साथियों को भेजे जाने वाले डेटा को प्रभावित किए बिना कम (या नहीं) दर सीमा होती है।

• ● Core Lightning #5275 शून्य-कॉन्फ़ चैनल खोलता है और संबंधित लघु चैनल पहचानकर्ता (एससीआईडी) उपनामों के लिए समर्थन जोड़ता है (देखें न्यूज़लेटर #203)। इसमें listpeers, fundchannel और multifundchannel RPC के अपडेट शामिल हैं।

• ● LND #5955, ऊपर सूचीबद्ध मर्ज की तरह, शून्य-कॉन्फ़ चैनल खोलने और संबंधित SCID उपनामों के लिए भी समर्थन जोड़ता है।

• ● LDK #1567 एक बुनियादी भुगतान जांच API के लिए समर्थन जोड़ता है जिसका उपयोग किसी एप्लिकेशन द्वारा यह परीक्षण करने के लिए किया जा सकता है कि भुगतान के माध्यम से भुगतान भेजे जाने पर कौन से भुगतान मार्गों के सफल होने की अधिक संभावना होगी। निकट भविष्य। इसमें HTLCs के निर्माण के लिए समर्थन शामिल है जो भेजने वाले नोड को वास्तविक भुगतान HTLCs से अलग करने की अनुमति देता है जब वे बिना किसी अतिरिक्त स्थिति को संग्रहीत किए वापस आते हैं।

• ● LDK #1589 एक सुरक्षा नीति जोड़ता है जिसका उपयोग LDK अनुरक्षकों को सुरक्षा कमजोरियों की सुरक्षित रूप से रिपोर्ट करने के लिए किया जा सकता है।

• ● BTCPay Server #3922 कस्टोडियन अकाउंट्स के लिए बेसिक UI जोड़ता है —-BTCPay इंस्टेंस में बंधे खाते जहां फंड को एक कस्टोडियन द्वारा प्रबंधित किया जाता है, जैसे कि Bitcoin एक्सचेंज (बजाय स्थानीय उपयोगकर्ता द्वारा उनके नियंत्रण को नियंत्रित करने के लिए) निजी कुंजी)। BTCPay इंस्टेंस में स्थानीय वॉलेट और कस्टोडियन दोनों खाते हो सकते हैं, जिससे उनके बीच फंड का प्रबंधन करना आसान हो जाता है, उदा। एक व्यापारी को निजी तौर पर और सुरक्षित रूप से अपने बटुए में धन प्राप्त करने की अनुमति देता है, लेकिन साथ ही बेचे जाने वाले एक्सचेंज में राशियों को जल्दी से स्थानांतरित करता है।

• ● BDK #634 एक get_block_hash विधि जोड़ता है जो एक विशेष ऊंचाई पर सर्वश्रेष्ठ ब्लॉक श्रृंखला पर एक ब्लॉक के लिए हेडर हैश देता है।

• ● BDK #614 अपरिपक्व कॉइनबेस आउटपुट — आउटपुट से लेकर माइनर के कॉइनबेस ट्रांजैक्शन तक खर्च करने वाले लेन-देन से बचता है, जिसमें 100 से कम पुष्टिकरण (उस ब्लॉक के शीर्ष पर बने ब्लॉक) होते हैं।