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

समाचार

  • ● निरंतर पैकेज रिले BIP चर्चा: पैकेज रिले के लिए हाल ही में एक मसौदा BIP (देखें Newsletter #201) को पिछले कई हफ्तों में अतिरिक्त टिप्पणियां मिली हैं:

    • ● नीति सीमाएं: Anthony Towns पूछे गए यदि पैकेज रिले का समर्थन करने के लिए दो साथियों के बीच बातचीत में प्रत्येक सहकर्मी के पैकेज के बारे में अधिकतम आकार और गहराई सीमा के बारे में जानकारी शामिल होनी चाहिए, अन्यथा गैर-डिफ़ॉल्ट सेटिंग्स वाले नोड्स को इसके बारे में बार-बार सूचनाएं प्राप्त हो सकती हैं। वे पैकेज जो वे नहीं चाहते थे, बैंडविड्थ बर्बाद कर रहे थे। BIP लेखिका Gloria Zhao सुझाव देती हैं पैकेज रिले प्रोटोकॉल के पहले संस्करण का उपयोग करते हुए अधिकतम 25 लेनदेन और 101,000 vbytes का पैकेज आकार होना चाहिए।

    • ● केवल पैकेज ग्राफ घोषणा: Eric Voskuil सिफारिश करता है कि एक सहकर्मी जो कम-फीट पूर्वज के उच्च-फीट वंशज के बारे में सीखता है, उसे अपने साथियों को उन दो लेनदेन के बीच संबंधों के बारे में सूचित करना चाहिए, जिन्हें पैकेज ग्राफ कहा जाता है। एक प्राप्त करने वाला सहकर्मी तब किसी भी लेनदेन का अनुरोध कर सकता है जो उसके पास नहीं है। धागे के एक अलग हिस्से में, Towns नोट्स कि एक ग्राफ को तब तक मान्य नहीं किया जा सकता है जब तक कि सभी लेनदेन प्राप्त नहीं हो जाते हैं, इसलिए यह सुनिश्चित करने के लिए ध्यान रखा जाना चाहिए कि एक सहकर्मी ग्राफ के बारे में झूठ नहीं बोल सकता है। लेन-देन को अन्य साथियों द्वारा रिले किए जाने से रोकें।

    • ● लघु आईडी का उपयोग करना: कई डेवलपर्स ने BIP152-शैली के लघु पहचानकर्ताओं (आईडी) का उपयोग करने का सुझाव दिया। झाओ समझाया कि छोटी आईडी ब्लॉक रिले के लिए समझ में आती है जहां नोड्स पहले एक नए ब्लॉक के काम के सबूत (जो बनाने के लिए महंगा है) को मान्य करते हैं, इसलिए एक हमलावर के लिए नोड संसाधनों को बर्बाद करने के लिए तंत्र का दुरुपयोग करना महंगा होगा। लेकिन, डेटा के रिले के लिए जो बनाने के लिए सस्ता है, शॉर्ट आईडी का बार-बार दुरुपयोग किया जा सकता है ताकि संभावित रूप से सेवा से इनकार किया जा सके।

    • ● गैर-मानक माता-पिता: Suhas Daftuar वर्णन एक परिदृश्य जहां एक नोड कार्यान्वयन पैकेज रिले एक ही डेटा का बार-बार अनुरोध कर सकता है। यह विशेष रूप से तब होने की संभावना है जब रिले नीति पुराने और नए नोड्स के बीच भिन्न होती है, जैसे कि सॉफ्ट फोर्क सक्रिय होने के बाद।

    • ● ब्लॉक हैश बीकन की चुनौतियाँ: Daftuar यह भी नोट करता है कि प्रस्ताव की एक विशेषता अन्य सॉफ़्टवेयर के लिए समस्याएँ पैदा कर सकती है। वर्तमान मसौदा BIP में प्रत्येक पैकेज घोषणा में ब्लॉक श्रृंखला पर नवीनतम ब्लॉक के नोड का वर्तमान हैश शामिल है। यह प्राप्त करने वाले सहकर्मी को किसी पैकेज को अनदेखा करने की अनुमति देता है यदि यह पहले के ब्लॉक (या वैकल्पिक श्रृंखला) से है, तो इस स्थिति में पैकेज प्राप्त करने वाले सहकर्मी के वर्तमान मेमपूल के साथ काम नहीं कर सकता है। हालाँकि, Daftuar नोट करता है कि संभवतः बहुत सारे सॉफ़्टवेयर हैं जो लेन-देन भेजते हैं — और जो अंततः पैकेज भेजना पसंद कर सकते हैं — जो वर्तमान श्रृंखला टिप हैश का ट्रैक नहीं रखता है।

  • ● LN डेवलपर मीटिंग का सारांश: Olaoluwa Osuntokun ने पिछले सप्ताह Oakland में LN देव मीटिंग का विस्तृत सारांश प्रदान किया। शामिल विषयों में शामिल हैं:

    • ● Taproot-आधारित LN चैनल: प्रतिभागियों ने LN को [Taproot]​​topic taproot ​​सुविधाओं के पूर्ण उपयोग के लिए ले जाने के लिए पहले चरणों पर चर्चा की। बाद के चरणों में PTLCs के लिए समर्थन शामिल होने की संभावना है (यह भी देखें Newsletter #164)।

    • ● TapScript और MuSig2: Taproot-आधारित चैनलों पर स्विच के हिस्से के रूप में, मौजूदा स्क्रिप्ट को टैपस्क्रिप्ट में बदलने की आवश्यकता है जिससे ब्लॉक स्पेस का सबसे कुशल उपयोग हो सके। उन सभी जगहों पर हस्ताक्षर बनाने के लिए MuSig2 का उपयोग करने की भी इच्छा है जहां दोनों हस्ताक्षरकर्ताओं से सहयोगात्मक रूप से कार्य करने की उम्मीद की जाती है। यह सुनिश्चित करने के लिए कि वे अपेक्षित रूप से काम करते हैं, इन दोनों को लागू करने और परीक्षण करने की आवश्यकता है।

    • ● Recursive MuSig2: MuSig2 का एक सरल कार्यान्वयन ऐलिस और बॉब को संयुक्त रूप से एकल हस्ताक्षर बनाने की अनुमति दे सकता है। रिकर्सिव Musig2, उदाहरण के लिए, ऐलिस को अपने हॉट वॉलेट और हार्डवेयर साइनिंग डिवाइस दोनों का उपयोग करके बॉब के बिना कोई विशेष कदम उठाए या यहां तक ​​​​कि यह जानते हुए भी कि ऐलिस एक से अधिक कुंजी के साथ हस्ताक्षर कर रहा था, हस्ताक्षर का अपना हिस्सा बनाने की अनुमति देगा। यह चर्चा की गई कि LN के MuSig2 के उपयोग को कैसे डिजाइन किया जाए ताकि यह सुनिश्चित हो सके कि रिकर्सिव Musig2 उपलब्ध था। साथ ही पुनरावर्ती MuSig2 की सुरक्षा पर भी चर्चा की गई।

    • ● Extension BOLTs LN प्रोटोकॉल विनिर्देश में परिवर्तन निर्दिष्ट करने का एक वैकल्पिक तरीका। वर्तमान में, विनिर्देश में परिवर्तन मौजूदा विनिर्देश के पैच (diff) के रूप में किए जाते हैं। हालांकि, कुछ डेवलपर्स BIP के लिए इस्तेमाल की जाने वाली विधि को पसंद करते हैं जहां प्रोटोकॉल में बड़े बदलाव उन परिवर्तनों के लिए विशिष्ट एक या अधिक दस्तावेजों में निर्दिष्ट होते हैं। उन डेवलपर्स का मानना ​​​​है कि अलग-अलग दस्तावेज़ लिखना और पढ़ना आसान है, और इसलिए विकास को सरल और तेज कर सकते हैं।

    • ● गॉसिप नेटवर्क अपडेट: बैठक ने LN गपशप को अद्यतन करने के बारे में मौजूदा चर्चा जारी रखी (देखें Newsletter #188), जिसका उपयोग नए और अपडेट किए गए चैनलों के बारे में घोषणाओं को रिले करने के लिए किया जाता है। सारांश के अनुसार, प्रतिभागी MuSig2-आधारित Taproot चैनलों का समर्थन करने के लिए प्रोटोकॉल के एक छोटे से उन्नयन पर अल्पावधि में ध्यान केंद्रित करना पसंद करेंगे और TLV शब्दार्थ का पूरी तरह से उपयोग करने के लिए प्रोटोकॉल को अपग्रेड करेंगे।

    • ● Minisketch-आधारित कुशल गपशप: जैसा कि Newsletter #198 में उल्लेख किया गया है, नोड्स के बीच LN गॉसिप को सिंक करने के लिए उपयोग की जाने वाली बैंडविड्थ की मात्रा को कम करने के लिए minisketch का उपयोग करने के लिए अनुसंधान जारी है, जो हो सकता है अद्यतनों के बीच न्यूनतम अनुमत समय को कम करने की भी अनुमति देता है।

    • ● अनियन संदेश DoS: कई LN कार्यान्वयन पहले से ही अनियन संदेश का समर्थन करते हैं, संदेश भेजने के लिए keysend भुगतान का उपयोग करने के विकल्प के रूप में और प्रस्तावित BOLT12 ऑफ़र प्रोटोकॉल के लिए संचार परत के रूप में। हालाँकि, जैसा कि Newsletter #190 में उल्लेख किया गया है, कुछ डेवलपर्स चिंतित रहते हैं कि onion संदेश कई अलग-अलग प्रकार के सेवा से इनकार करने वाले हमलों के प्रति संवेदनशील हो सकते हैं। DoS हमलों को रोकने के कई तरीकों पर चर्चा की गई।

    • ● ब्लाइंड हुए रास्ते: कई साल पहले प्रस्तावित एक तकनीक (देखें Newsletter #85) और अब अनियन संदेशों के लिए उपयोग किया जाता है, उपयोगकर्ताओं को अपनी पहचान का खुलासा किए बिना भुगतान प्राप्त करने की अनुमति देने के लिए नियमित भुगतान के साथ प्रयोग के लिए प्रयोग भी देखा जा रहा है। उनके LN नोड। इस दृष्टिकोण के सामने एक चुनौती यह है कि इसके लिए अधिक रूटिंग जानकारी संप्रेषित करने की आवश्यकता होती है, इसलिए बड़े चालानों की आवश्यकता होती है। यह नए इनवॉइस-प्रबंधन प्रोटोकॉल जैसे कि BOLT12 ऑफ़र या LNURL पर निर्भर ब्लाइंड रास्तों का प्रभावी कार्यान्वयन कर सकता है। कई अन्य चिंताओं पर भी चर्चा की गई।

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

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

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

    • ● LNURL plus BOLT12: LNURL प्रोटोकॉल एक नोड को वेबसर्वर से BOLT11 इनवॉइस का अनुरोध करने की अनुमति देता है; BOLT12 ऑफ़र्स प्रोटोकॉल नेटवर्क पर एक नोड से इनवॉइस का अनुरोध करने की अनुमति देता है। इन प्रोटोकॉल के अन्य पहलुओं में, प्रतिभागियों ने चर्चा की कि कैसे दो प्रोटोकॉल को एक-दूसरे के साथ संगत बनाया जा सकता है ताकि नोड्स दोनों में से किसी एक या दोनों का उपयोग कर सकें।

  • ● तरलता का संकेत देने के लिए रूटिंग शुल्क का उपयोग करना: डेवलपर ZmnSCPxj पोस्ट किया गया Lightning-देव मेलिंग सूची में एक तर्क है कि कैसे खर्च करने वालों और रूटिंग नोड्स के बीच गेम थ्योरेटिक व्यवहार के माध्यम से बेहतर सस्ते और विश्वसनीय भुगतान प्राप्त किए जा सकते हैं:

    • खर्च करने वालों को उन रास्तों का चयन करना चाहिए जो रूटिंग शुल्क में कम शुल्क लेते हैं।

    • रूटिंग नोड्स को चैनल का उपयोग करने के लिए अधिक चार्ज करना चाहिए क्योंकि इसकी क्षमता घट जाती है। उदाहरण के लिए, यदि चैनल में अधिकांश शेष राशि ऐलिस के स्वामित्व में है, तो वह विश्वसनीय रूप से बॉब को भुगतान अग्रेषित कर सकती है और इसलिए उसे अधिक शुल्क नहीं लेना चाहिए; लेकिन, जैसे-जैसे अधिक शेष राशि बॉब की ओर अग्रेषित की जाती है, ऐलिस की अतिरिक्त भुगतान अग्रेषित करने की क्षमता कम हो जाती है, इसलिए उसे अधिक शुल्क लेना चाहिए।

    ZmnSCPxj आपूर्ति और मांग अर्थशास्त्र का उपयोग करके इस तर्क को फ्रेम करता है — जैसे-जैसे एक दिशा में भुगतान को रूट करने की मांग बढ़ती है, उदा। ऐलिस से बॉब तक, अतिरिक्त सतोशी की आपूर्ति जो उस दिशा में रूट की जा सकती है, स्वाभाविक रूप से कम हो जाती है। रूटिंग शुल्क की कीमत बढ़ाने से मांग कम हो सकती है जब तक कि दूसरी दिशा में भुगतान करने वाले लोगों के माध्यम से आपूर्ति फिर से बढ़ जाती है (जैसे बॉब से ऐलिस तक)।

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

    इस दृष्टिकोण का एक प्रमुख लाभ यह है कि यह खर्च करने वालों के लिए रास्ता खोजना बहुत आसान बनाता है — वे केवल क्षमता सीमा के भीतर सबसे सस्ते मार्गों पर भुगतान करने का प्रयास करते हैं। एक कमी यह है कि उच्च-निम्न/निम्न-उच्च रणनीति के तहत रूटिंग नोड्स शुल्क में प्रत्येक परिवर्तन चैनल के संतुलन में एक समान परिवर्तन का अर्थ है, भुगतान के आकार के बारे में जानकारी का खुलासा करना जो हाल ही में उस चैनल में प्रवाहित हो सकता है। उदाहरण के लिए, यदि चैनल एलिस → बॉब, बॉब → कैरल, और कैरल → डैन सभी हाल ही में क्षमता में लगभग 1 BTC कम हो गए हैं, तो यह अनुमान लगाना उचित है कि ऐलिस या उसके किसी चैनल पार्टनर ने डैन को 1 BTC भुगतान किया है या उनके चैनल भागीदारों में से एक। एक अतिरिक्त समस्या यह है कि चैनल की फीस में प्रत्येक परिवर्तन को पूरे नेटवर्क में गपशप करने की आवश्यकता होती है, जो बैंडविड्थ आवश्यकताओं को बढ़ाता है और जो नकली रूटिंग विफलताओं का कारण बन सकता है (उदाहरण के लिए क्योंकि स्पेंडर सैली ने ऐलिस के नए उच्च शुल्क के बारे में नहीं सुना है और इसलिए रूटिंग का प्रयास करता है एलिस से बॉब को पुराने और कम शुल्क का उपयोग करके पूरे चैनल में भुगतान जिसे एलिस अस्वीकार कर देता है)।

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

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

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

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

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

इस सप्ताह 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 #24171 इनबाउंड पीयर्स से ब्लॉक डेटा का अनुरोध करने के लिए प्रारंभिक ब्लॉक डाउनलोड (आईबीडी) व्यवहार में संशोधन करता है यदि कोई आउटबाउंड पीयर ब्लॉक डेटा की सेवा नहीं कर रहा है। पहले, एक नोड केवल इनबाउंड पीयर से डेटा का अनुरोध करेगा यदि उसके पास कोई आउटबाउंड पीयर नहीं था। यह व्यवहार एक स्टाल का कारण बन सकता है यदि नोड में केवल आउटबाउंड पीयर थे जो ब्लॉक की सेवा नहीं करते थे। जैसे ही कोई आउटबाउंड पीयर ब्लॉक की सेवा करता है, नोड्स अभी भी केवल आउटबाउंड पीयर से डेटा का अनुरोध करते हैं।

  • ● BDK #593 rust bitcoin 0.28 का उपयोग करना शुरू करता है, जिसमें Taproot और Taproot आउटपुट स्क्रिप्ट डिस्क्रिप्टर के लिए समर्थन शामिल है।