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

समाचार

  • ● LN-पेनल्टी के लिए डिज़ाइन की गई प्रस्तावित नई लेनदेन रिले नीतियां: Gloria Zhao द्वारा पोस्ट किया गया Bitcoin-Dev मेलिंग सूची में लेनदेन रिले नीतियों के संशोधित सेट में लेनदेन को ऑप्ट-इन करने की अनुमति देने का प्रस्ताव है। कोई भी लेन-देन जो इसके संस्करण पैरामीटर को 3 पर सेट करता है:

    • ● उच्च शुल्क और उच्च कुल शुल्क (वर्तमान मुख्य RBF नियम) का भुगतान करने वाले लेनदेन द्वारा अपुष्ट होने पर इसे बदलने योग्य बनें।

    • जब तक यह अपुष्ट रहता है, तब तक इसके सभी वंशजों को भी v3 लेन-देन की आवश्यकता होती है। इस नियम का उल्लंघन करने वाले वंशजों को डिफ़ॉल्ट रूप से रिले या खनन नहीं किया जाएगा

    • अगर इसके किसी भी v3 अपुष्ट पूर्वजों में से कोई भी पहले से ही mempool में कोई अन्य वंशज है (या पैकेज में यह लेनदेन शामिल है) तो खारिज कर दिया जाएगा।

    • अगर इसके किसी भी v3 पूर्वजों की पुष्टि नहीं हुई है तो 1,000 vbytes या उससे कम होने की आवश्यकता है

    प्रस्तावित रिले नियमों के साथ पहले से प्रस्तावित पैकेज रिले नियमों का एक सरलीकरण था (देखें न्यूज़लेटर #167)।

    साथ में, v3 रिले और अपडेट किए गए पैकेज रिले नियमों को LN प्रतिबद्धता लेनदेन को केवल न्यूनतम शुल्क (या संभावित रूप से शून्य शुल्क) शामिल करने की अनुमति देने के लिए डिज़ाइन किया गया है और एक चाइल्ड ट्रांसक्शन के लेनदेन द्वारा उनकी वास्तविक फीस का भुगतान किया जाता है, जबकि सभी पिनिंग को रोकते हैं। ]. लगभग सभी LN नोड्स पहले से ही इस तरह के एक तंत्र का उपयोग करते हैं, एंकर आउटपुट, लेकिन प्रस्तावित अपग्रेड को प्रतिबद्धता लेनदेन को सरल और अधिक मजबूत बनाना चाहिए।

    Greg Sanders उत्तर दिया दो सुझावों के साथ:

    • ● क्षणिक डस्ट: शून्य-मूल्य (या अन्यथा अलाभकारी) आउटपुट का भुगतान करने वाले किसी भी लेन-देन को डस्ट नीति से छूट दी जानी चाहिए यदि वह लेनदेन एक पैकेज का हिस्सा है जो डस्ट उत्पादन खर्च करता है।

    • ● मानक OP_TRUE: जो पूरी तरह से OP_TRUE वाले आउटपुट का भुगतान करने वाले आउटपुट को डिफ़ॉल्ट रूप से रिले किया जाना चाहिए। ऐसा आउटपुट कोई भी खर्च कर सकता है — इसकी कोई सुरक्षा नहीं है। इससे LN चैनल (या यहां तक ​​कि तीसरे पक्ष) के लिए किसी भी पक्ष के लिए लेनदेन खर्च करने के लिए शुल्क-बम्प करना आसान हो जाता है जो OP_TRUE आउटपुट करता है। एक OP_TRUE आउटपुट खर्च करने के लिए Stack पर कोई डेटा डालने की आवश्यकता नहीं है, जिससे इसे खर्च करना किफ़ायती हो जाता है।

    इनमें से किसी को भी v3 लेनदेन के रिले को लागू करने के साथ-साथ करने की आवश्यकता नहीं है, लेकिन थ्रेड के कई उत्तरदाता सभी प्रस्तावित परिवर्तनों के पक्ष में प्रतीत होते हैं।

  • ● LN प्रवाह नियंत्रण: Lightning-Dev मेलिंग सूची में Rene Pickhardt पोस्ट किया गया recent research का सारांश है जो उन्होंने प्रवाह के रूप में htlc_maximum_msat पैरामीटर का उपयोग करने पर किया था। नियंत्रण वॉल्व। BOLT7 में पहले परिभाषित के रूप में, htlc_maximum_msat वह अधिकतम मान है जो एक नोड एक व्यक्तिगत भुगतान भाग (HTLC) के लिए किसी विशेष चैनल में अगले हॉप को अग्रेषित करेगा। Pickhardt एक चैनल की समस्या का समाधान करता है, जिसके माध्यम से दूसरी दिशा की तुलना में एक दिशा में अधिक मूल्य प्रवाहित होता है — अंततः चैनल को बिना अधिक उपयोग किए गए दिशा में स्थानांतरित करने के लिए पर्याप्त धन के बिना छोड़ देता है। उनका सुझाव है कि अति प्रयोग की दिशा में अधिकतम मूल्य को सीमित करके चैनल को संतुलन में रखा जा सकता है। उदाहरण के लिए, यदि कोई चैनल किसी भी दिशा में 1,000 को आगे बैठने की अनुमति देकर शुरू करता है लेकिन असंतुलित हो जाता है, तो अधिक उपयोग की गई दिशा की अधिकतम राशि प्रति अग्रेषित भुगतान 800 तक कम करने का प्रयास करें। Pickhardt का शोध कई कोड स्निपेट प्रदान करता है जिनका उपयोग वास्तविक उपयुक्त htlc_maximum_msat मूल्य की गणना के लिए किया जा सकता है।

    अलग ईमेल में, Pickhardt ने यह भी सुझाव दिया है कि शुल्क रेटकार्ड (पिछले सप्ताह के न्यूज़लेटर देखें) का पिछला विचार इसके बजाय अधिकतम राशि प्रति-फ़ॉरवर्ड रेटकार्ड बन सकता है, जहाँ एक खर्च करने वाला छोटे भुगतान भेजने के लिए कम शुल्क और बड़े भुगतान भेजने के लिए उच्च शुल्क लिया जाएगा। मूल रेटकार्ड प्रस्ताव के विपरीत, वे पूर्ण मात्रा में होंगे और चैनल के वर्तमान शेष के सापेक्ष नहीं होंगे। Anthony Towns वर्णित मूल रेटकार्ड विचार के साथ कई चुनौतियां हैं जो htlc_maximum_msat को समायोजित करने के आधार पर प्रवाह नियंत्रण के लिए समस्या नहीं होगी।

    ZmnSCPxj आलोचना विचार के कई पहलू, जिसमें यह नोट करना शामिल है कि खर्च करने वाले अभी भी कम-अधिकतम दर चैनल के माध्यम से समान मात्रा में मूल्य भेज सकते हैं, जिसके परिणामस्वरूप यह फिर से असंतुलित हो जाता है, बस एक समग्र भुगतान को अतिरिक्त छोटे में विभाजित करके भागों। कस्बों ने सुझाव दिया कि इसे संभावित रूप से दर सीमित करके संबोधित किया जा सकता है।

    जब यह सारांश लिखा जा रहा था, तब चर्चा जारी थी, लेकिन हम उम्मीद करते हैं कि आने वाले हफ्तों और महीनों में कई नई अंतर्दृष्टि आएगी क्योंकि नोड ऑपरेटर अपने चैनल htlc_maximum_msat मापदंडों के साथ प्रयोग करना शुरू करते हैं।

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

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

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

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

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

  • ● Eclair #2435 जब Trampoline रिले का उपयोग किया जाता है, तो aync भुगतान के मूल रूप के लिए वैकल्पिक समर्थन जोड़ता है। जैसा कि न्यूज़लेटर #171 में वर्णित है, aync भुगतान किसी तीसरे पक्ष पर निधियों पर भरोसा किए बिना ऑफ़लाइन नोड (जैसे मोबाइल वॉलेट) का भुगतान करने की अनुमति देगा। async भुगतान के लिए आदर्श तंत्र PTLCs पर निर्भर करता है, लेकिन आंशिक कार्यान्वयन के लिए केवल तीसरे पक्ष को धन अग्रेषित करने में देरी की आवश्यकता होती है जब तक कि ऑफ़लाइन नोड ऑनलाइन वापस न आ जाए। Trampoline नोड्स उस देरी को प्रदान कर सकते हैं और इसलिए यह PR async भुगतान के साथ प्रयोग की अनुमति देने के लिए उनका उपयोग करता है।

  • ● BOLTs #962 विनिर्देश से मूल निश्चित लंबाई वाले onion डेटा प्रारूप के लिए समर्थन को हटा देता है। उन्नत चर-लंबाई प्रारूप को तीन साल पहले विनिर्देश में जोड़ा गया था और प्रतिबद्ध संदेश में उल्लिखित परीक्षण परिणामों से संकेत मिलता है कि अब कोई भी पुराने प्रारूप का उपयोग नहीं कर रहा है।

  • ● BIPs #1370 वर्तमान प्रस्तावित कार्यान्वयन को प्रतिबिंबित करने के लिए BIP330 (Erlay सामंजस्य-आधारित लेनदेन घोषणाओं के लिए) को संशोधित करता है। परिवर्तनों में शामिल हैं:

    • केवल लेन-देन wtxids का उपयोग करने के पक्ष में काटे गए लेन-देन आईडी को हटाना। इसका मतलब यह भी है कि नोड्स मौजूदा inv और getdata संदेशों का उपयोग कर सकते हैं, इसलिए invtx और gettx संदेशों को हटा दिया गया है।

    • sendrecon का नाम बदलकर sendtxrcncl, reqreconcil को reqrecon, और reqbisec को reqsketchtext में बदलना।

    • sendtxrcncl का उपयोग करके समर्थन पर बातचीत के लिए विवरण जोड़ना।

  • ● BIPs #1367 जितना संभव हो सके BIP 340 और 341 का हवाला देकर BIP118 के SIGHASH_ANYPREVOUT के विवरण को सरल बनाता है।

  • ● BIPs #1349 BIP351 शीर्षक से “निजी भुगतान” जोड़ता है, जो BIP47 और Silent Payment से प्रेरित एक क्रिप्टोग्राफिक प्रोटोकॉल का वर्णन करता है। BIP एक नया भुगतान कोड प्रारूप पेश करता है जिसके अनुसार प्रतिभागी अपनी सार्वजनिक कुंजी के आगे समर्थित आउटपुट प्रकार निर्दिष्ट करते हैं। BIP47 के समान, प्रेषक प्राप्तकर्ता के भुगतान कोड के आधार पर रिसीवर के साथ साझा रहस्य स्थापित करने के लिए अधिसूचना लेनदेन का उपयोग करता है। फिर प्रेषक साझा रहस्य से प्राप्त अद्वितीय पतों पर कई भुगतान भेज सकता है जिसे प्राप्तकर्ता अधिसूचना लेनदेन से जानकारी का उपयोग करके खर्च कर सकता है। जहां BIP47 में कई प्रेषक प्रति प्राप्तकर्ता एक ही सूचना पते का पुन: उपयोग करते हैं, यह प्रस्ताव प्राप्तकर्ता का ध्यान आकर्षित करने और बेहतर गोपनीयता के लिए साझा रहस्य स्थापित करने के लिए खोज कुंजी PP के साथ लेबल किए गए OP_RETURN आउटपुट और प्रेषक-रिसीवर जोड़ी के लिए विशिष्ट अधिसूचना कोड का उपयोग करता है। .

  • ● BIPs #1293 BIP372 को जोड़ता है जिसका शीर्षक “PSBT के लिए भुगतान-से-अनुबंध ट्विक फ़ील्ड” है। यह BIP अतिरिक्त PSBT क्षेत्रों को शामिल करने के लिए एक मानक का प्रस्ताव करता है जो पे-टू-कॉन्ट्रैक्ट प्रोटोकॉल में भाग लेने के लिए आवश्यक अनुबंध प्रतिबद्धता डेटा के साथ हस्ताक्षर करने वाले उपकरण प्रदान करता है (देखें न्यूजलेटर # 184).

  • ● BIPs #1364 BIP300 drivechains के विनिर्देश के लिए पाठ में अतिरिक्त विवरण जोड़ता है। Drivechain के ब्लाइंड मर्ज माइनिंग नियमों को लागू करने के लिए BIP301 के संबंधित विनिर्देश भी अपडेट किए गए हैं।