इस सप्ताह का समाचार पत्र आकस्मिक LN उपयोगकर्ताओं को एक बार में कई महीनों तक ऑफ़लाइन रहने की अनुमति देने के प्रस्ताव को सारांशित करता है और लेनदेन सूचना Servers को अप्रयुक्त वॉलेट पते की मेजबानी करने की अनुमति देने के बारे में एक दस्तावेज का वर्णन करता है। Bitcoin Core PR Review Club के सारांश के साथ हमारे नियमित खंड भी शामिल हैं, नए Software रिलीज और रिलीज उम्मीदवारों की घोषणा (एक महत्वपूर्ण LND फिक्स सहित), और लोकप्रिय Bitcoin Infrastructure Software में उल्लेखनीय परिवर्तनों का विवरण।

समाचार

• ● LN लॉन्ग टाइमआउट प्रस्ताव के साथ: John Law पोस्ट किया गया Lightning-Dev मेलिंग सूची में एक प्रस्ताव आकस्मिक Lightning उपयोगकर्ताओं को बिना जोखिम के कई महीनों तक ऑफ़लाइन रहने की अनुमति देता है अपने चैनल भागीदारों को किसी भी धन को खोने के लिए। यद्यपि यह वर्तमान LN प्रोटोकॉल में तकनीकी रूप से संभव है, यह निपटान-देरी मानकों को उच्च मूल्यों पर सेट करने पर निर्भर करेगा जो एक दुखी उपयोगकर्ता या दुर्घटना को एक दर्जन से अधिक चैनलों में धन को उन्हीं महीनों के लिए उपयोग करने से रोकने की अनुमति देगा। Law का प्रस्ताव दो प्रोटोकॉल संशोधनों के माध्यम से उस समस्या को कम करता है:

  • ● ट्रिगर किए गए HTLCs: भुगतान के लिए उपयोग किए जाने वाले एक मानक HTLC में Alice ने Bob को BTC की कुछ राशि की पेशकश की है यदि वह किसी ज्ञात हैश डाइजेस्ट के लिए पहले से अज्ञात preimage प्रकाशित करने में सक्षम है। वैकल्पिक रूप से, यदि Bob एक ​​निश्चित समय तक preimage प्रकाशित नहीं करता है, तो Alice पैसे को अपने वॉलेट में वापस खर्च करने में सक्षम है।

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

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

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

    इसका मतलब है कि जब Alice चैनल को बंद करना चाहती है, तो वह केवल उचित शुल्क के साथ प्रतिबद्धता लेनदेन के अपने संस्करण को प्रसारित नहीं कर सकती है और मान सकती है कि इसकी पुष्टि हो जाएगी। उसे यह भी इंतजार करना होगा और जांचना होगा कि क्या Bob इसके बजाय प्रतिबद्धता लेनदेन के अपने संस्करण की पुष्टि करता है, इस मामले में उसे अपने लेनदेन को सत्यापित करने के लिए अतिरिक्त कार्य करने की आवश्यकता हो सकती है जिसमें नवीनतम चैनल स्थिति शामिल है।

    Law का प्रस्ताव है कि Alice का प्रतिबद्धता लेनदेन का संस्करण आज जैसा ही है ताकि वह इसे किसी भी समय प्रकाशित कर सके, लेकिन Bob के संस्करण में एक टाइम Lock शामिल है ताकि वह इसे केवल तभी प्रकाशित कर सके जब Alice लंबे समय से निष्क्रिय हो। आदर्श रूप से, यह Alice को नवीनतम राज्य को इस ज्ञान में सुरक्षित रूप से प्रकाशित करने की अनुमति देता है कि Bob एक ​​विरोधाभासी संस्करण प्रकाशित नहीं कर सकता है, जिससे वह अपने प्रकाशन के बाद सुरक्षित रूप से ऑफ़लाइन हो सकती है।

  Law के प्रस्तावों को अभी भी प्रारंभिक प्रतिक्रिया मिल रही थी क्योंकि यह विवरण लिखा जा रहा था।

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

  विधि कैसे काम कर सकती है, इसके एक उदाहरण के लिए, Alice का वॉलेट example.com Electrum-स्टाइल Server पर 100 पते दर्ज करता है। फिर वह अपने ईमेल हस्ताक्षर में “example.com/alice” शामिल करती है। जब Bob Alice को धन दान करना चाहता है, तो वह उसके URL पर जाता है, एक पता प्राप्त करता है, सत्यापित करता है कि Alice ने उस पर हस्ताक्षर किए हैं, और फिर उसे भुगतान करता है।

  आंशिक रूप से मैन्युअल प्रक्रिया के माध्यम से कई पर्स के साथ व्यापक रूप से संगत होने और स्वचालित प्रक्रिया के साथ लागू करने में संभवतः आसान होने का विचार है। इसका नकारात्मक पक्ष यह है कि जो उपयोगकर्ता पहले से ही Server के साथ पते साझा करके अपनी गोपनीयता से समझौता कर रहे हैं, वे आगे गोपनीयता हानि के लिए प्रतिबद्ध होंगे।

  जिस समय यह सारांश लिखा जा रहा था, उस समय मेलिंग सूची और दस्तावेज़ दोनों पर सुझावों की चर्चा चल रही थी।

Bitcoin Core PR Review Club

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

फिक्स सीड्स के लिए AddrFetch कनेक्शन बनाएं Martin Zumsande का एक PR है जो AddrFetch कनेक्शन को फिक्स्ड सीड्स (हार्ड-कोडेड आईपी एड्रेस) से जोड़ता है, बजाय इसके कि उन्हें AddrMan में जोड़ा जाए ( हमारे साथियों का डेटाबेस)।

• जब एक नया नोड शुरू से शुरू होता है, तो उसे पहले कुछ साथियों से जुड़ना होगा, जिनसे वह इनिशियल ब्लॉक डाउनलोड (IBD) करेगा। किन परिस्थितियों में यह फिक्स्ड से जुड़ता है सीड?

  केवल अगर यह उन साथियों से कनेक्ट करने में सक्षम नहीं है जिनके पते हार्ड-कोडेड Bitcoin DNS सीड नोड्स द्वारा प्रदान किए गए हैं। यह आमतौर पर तब होता है जब नोड को IPv4 या IPv6 का उपयोग नहीं करने के लिए कॉन्फ़िगर किया जाता है (उदाहरण के लिए, -onlynet = Tor)। ➚

• यह PR किस व्यवहार में देखने योग्य परिवर्तन पेश करता है? हम AddrMan में किस प्रकार के पते जोड़ते हैं, और किन परिस्थितियों में?

  नोड, निश्चित सीड्स को अपने AddrMan में तुरंत जोड़ने और उनमें से कुछ के साथ पूर्ण कनेक्शन बनाने के बजाय, उनमें से कुछ के लिए AddrFetch कनेक्शन बनाता है, और returned address को AddrMan में जोड़ता है। ( AddrFetch अल्पकालिक कनेक्शन हैं जिनका उपयोग केवल पते लाने के लिए किया जाता है।) नोड फिर IBD करने के लिए अपने AddrMan में कुछ पतों से जुड़ता है। इसके परिणामस्वरूप फिक्स्ड-सीड नोड्स के लिए कम पूर्ण कनेक्शन होते हैं; इसके बजाय, फिक्स्ड-सीड नोड्स के बारे में हमें बताए गए नोड्स के बहुत बड़े सेट से अधिक कनेक्शन का प्रयास किया जाता है। AddrFetch कनेक्शन any प्रकार के पते लौटा सकते हैं, उदाहरण के लिए, Tor; परिणाम IPv4 और IPv6 तक सीमित नहीं हैं। ➚

• हम फिक्स्ड सीड्स के लिए एक पूर्ण आउटबाउंड कनेक्शन के बजाय एक AddrFetch कनेक्शन क्यों बनाना चाहते हैं? एक निश्चित सीड के पीछे नोड ऑपरेटर भी इसे क्यों पसंद कर सकता है?

  एक AddrFetch कनेक्शन हमारे नोड को साथियों के एक बहुत बड़े समूह से IBD साथियों को चुनने की अनुमति देता है, जो समग्र नेटवर्क कनेक्टिविटी वितरण को बढ़ाता है। निश्चित सीड नोड ऑपरेटरों के पास एक साथ कई IBD सहकर्मी होने की संभावना कम होगी, जो संसाधन को कम करता है उनके नोड्स पर आवश्यकताएं। ➚

• DNS सीड नोड्स के उत्तरदायी होने और Bitcoin नोड्स के अप-टू-डेट पते की सेवा करने की अपेक्षा की जाती है। यह -onlynet=tor नोड की मदद क्यों नहीं करता है?

  DNS सीड नोड केवल IPv4 और IPv6 पते प्रदान करते हैं; वे किसी अन्य प्रकार के पते की आपूर्ति करने में सक्षम नहीं हैं। ➚

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

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

• ● LND v0.15.2-beta एक सुरक्षा महत्वपूर्ण आपातकालीन रिलीज़ है जो एक पार्सिंग त्रुटि को ठीक करती है जो LND को कुछ ब्लॉकों को पार्स करने में सक्षम होने से रोकती है। सभी यूजर्स को अपग्रेड करना चाहिए।

• ● 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।

• ● LND #6500 प्लेन टेक्स्ट में स्टोर करने के बजाय वॉलेट की निजी कुंजी का उपयोग करके डिस्क पर Tor निजी कुंजी को एन्क्रिप्ट करने की क्षमता जोड़ता है। फ्लैग का उपयोग करते हुए, --tor.encryptkey, LNडी निजी कुंजी को एन्क्रिप्ट करता है और एन्क्रिप्टेड blob डिस्क पर उसी फ़ाइल में लिखा जाता है, जिससे उपयोगकर्ता अभी भी वही कार्यक्षमता (जैसे किसी छिपी हुई सेवा को रीफ्रेश करना) रखने की इजाजत देता है, लेकिन सुरक्षा जोड़ता है जब अविश्वसनीय वातावरण में चल रहा है।