इस सप्ताह के न्यूजलेटर में हमारे नियमित खंड के साथ शामिल हैं Bitcoin core PR review Club मीटिंग का सारांश, नए सॉफ्टवेयर रिलीज और रिलीज उम्मीदवारों की एक सूची, और लोकप्रिय बिटकॉइन इंफ्रास्ट्रक्चर सॉफ्टवेयर पर किये गए उल्लेखनीय परिवर्तन का विवरण।

समाचार

इस हफ्ते कोई खास खबर नहीं है।

Bitcoin Core PR Review Club

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

Miniscript support in Output Descriptors Antoine Poinsot और Pieter Wuille द्वारा पीआर, descriptors में निगरानी के लिए समर्पित Miniscript के लिए समर्थन का परिचय देता है। प्रतिभागियों ने दो बैठकों में पीआर की समीक्षा की। चर्चा के विषय थे मिनिस्क्रिप्ट का उपयोग, मैलिएबिलिटी पर विचार और डिस्क्रिप्टर पार्सर्स का कार्यान्वयन।

  • Miniscript के साथ किये गए किस प्रकार के विश्लेषण किन प्रकार के मामलों और अनुप्रयोगों में सहायक है?

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

  • मिनिस्क्रिप्ट अभिव्यक्तियों को नोड्स के पेड़ के रूप में दर्शाया जा सकता है, जहां प्रत्येक नोड एक टुकड़े का प्रतिनिधित्व करता है। इसका क्या अर्थ है कि एक नोड समझदार(sane) या मान्य(valid) है? क्या इनका मतलब एक ही है?

    प्रत्येक नोड में एक खंड प्रकार (and_v,thresh, multi, आदि) और एक आर्गुमेंट होता है। एक मान्य(valid) नोड के आर्गुमेंट खंड प्रकार की अपेक्षा से मेल खाते हैं। एक समझदार(sane) नोड मान्य होना चाहिए, और इसकी स्क्रिप्ट शब्दार्थ को इसकी नीति से मेल खाना चाहिए। उसे सर्वसम्मति-मान्य और मानक-अनुपालन होना चाहिए। उसके केवल गैर-मेलिएबले समाधान होना चाहिए। वह टाइमलॉक इकाइयों को नहीं मिलाये (यानी, ब्लॉक की ऊंचाई और समय दोनों का उपयोग करें), और इसमें डुप्लिकेट कुंजियाँ(keys) नहीं होनी चाहिए। जैसा कि परिभाषित किया गया है, ये दो गुण (मान्य(valid) नोड और समझदार(sane) नोड) समान नहीं हैं। हर समझदार(sane) नोड मान्य(valid) है, लेकिन प्रत्येक मान्य(valid) नोड समझदार(sane) नहीं है। 

  • इसका क्या अर्थ है कि सूत्र नॉन-मालिएबली(non-malleably) संतोषजनक है? क्या segwit को परिनियोजित करने के बाद भी हमे मैलिएबिलिटी के बारे में चिंता करनी होगी?

    एक स्क्रिप्ट मैलिएबिल है यदि कोई तृतीय पक्ष (उदाहरण के लिए, आपके पास संबंधित निजी कुंजी या अन्य पूर्वापेक्षाएँ तक पहुँच नहीं है) इसे संशोधित कर सकते हैं और अभी भी खर्च की शर्तों को पूरा कर सके। Segwit लेन-देन संबंधी क्राफ्टिंग की संभावना को पूरी तरह से समाप्त नहीं करता। यह सुनिश्चित करता है कि लेन-देन की क्राफ्टिंग अस्वीकृत वंशजों की वैधता को नहीं तोड़ेंगे। लेकिन क्राफ्टिंग की संभावना अभी भी अन्य कारणों से समस्यापूर्वक हो सकती है। उदाहरण के लिए, यदि कोई हमलावर अतिरिक्त डेटा को witness में पैक करता है और फिर भी उपयोग की शर्तों को पूरा करता है तब वह लेनदेन शुल्क दर को कम कर सकता है और लेनदेन के प्रसार पर प्रतिकूल प्रभाव डाल सकता है। एक ‘गैर-मेलिएबिली संतोषजनक अभिव्यक्ति’ तीसरे पक्ष को मौजूदा संतुष्टि को किसी अन्य वैध संतुष्टि में संशोधित करने के लिए ऐसे विकल्प नहीं देती है। एक और पूर्ण उत्तर पाया जा सकता है यहां। 

  • आउटपुट डिस्क्रिप्टर स्ट्रिंग को पार्स करने के लिए कौन सा फ़ंक्शन जिम्मेदार है? आप कैसे निर्धारित करते हैं कि स्ट्रिंग MiniscriptDescriptor का प्रतिनिधित्व करती है या नहीं? आप एक डिस्क्रिप्टर को कैसे हल करते हैं जिसे कई तरीकों से पार्स किया जा सकता है?

    script/ descriptor.cpp में ParseScript फ़ंक्शन आउटपुट डिस्क्रिप्टर स्ट्रिंग को पार्स करने के लिए ज़िम्मेदार है। यह पहले अन्य सभी डिस्क्रिप्टर प्रकारों को आज़माने की कोशिश करता है, और फिर यह miniscript::FromString फंक्शन को कॉल करता है यह देखने के लिए कि स्ट्रिंग मान्य Miniscript व्यंजक है या नहीं। इस ऑपरेशन आदेश के कारण वर्णनकर्ता जिनकी व्याख्या Miniscript और गैर-Miniscript दोनों के रूप में कि जा सकती है (जैसे wsh (pk (...))) उन्हें गैर-Miniscript के रूप में पार्स किया जाता है। 

  • उपलब्ध पर्याप्तता मानदंड में से चयन करते समय हमें छोटी स्क्रिप्ट के बजाय सबसे कम हस्ताक्षर वाल को प्राथमिकता क्यों देनी चाहिए?

    एक तृतीय पक्ष (अर्थात, जिसकी निजी कुंजी तक पहुंच नहीं है) लेन-देन के साथ छेड़छाड़ करने का प्रयास करके हस्ताक्षर हटा सकता हैं, लेकिन एक नया हस्ताक्षर नहीं बना सकता। अतिरिक्त हस्ताक्षरों के साथ संतुष्टि का चयन करने से तीसरे पक्ष के पास स्क्रिप्ट को खराब करने और खर्च करने की शर्तों को पूरा करने का विकल्प बचता है। उदाहरण के लिए, पॉलिसी or(and(older(21), pk(B)), thresh(2, pk(A), pk(B))) को खर्च करने के दो रास्ते है: इसे हमेशा खर्च किया जा सकता है जब दोनों A और B हस्ताक्षर करे , या 21 ब्लॉक के बाद जब सिर्फ B हस्ताक्षर करे। 21 ब्लॉक के बाद, दोनों संतुष्टि उपलब्ध हैं, लेकिन अगर A और B दोनों के हस्ताक्षर के साथ एक लेनदेन प्रसारित किया जाता है, तो एक तीसरा पक्ष A के हस्ताक्षर को हटा सकता है और फिर भी अन्य खर्च रास्ते को संतुष्ट कर सकता है। दूसरी ओर, यदि प्रसारण लेनदेन में केवल B के हस्ताक्षर होते हैं, तो हमलावर अन्य खर्च की शर्त को तब तक संतुष्ट नहीं कर सकता जब तक कि वह A के हस्ताक्षर नहीं करता। 

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

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

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

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

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

  • Bitcoin Core #24408 एक आरपीसी जोड़ता है जो किसी दिए गए Outpoint से खर्च किए गए mempool लेनदेन को प्राप्त करने के लिए है, जो getrawmempool से प्राप्त txid की सूची के बजाय व्यक्तिगत रूप से लेनदेन का चयन करके आउटपॉइंट की खोज को सुव्यवस्थित करता है। यह Lightning में तब उपयोगी होता है जब चैनल फंडिंग लेन-देन के खर्च होने के बाद खर्च के लेन-देन का पता लगाना या यह जांचना कि एक RBF लेन-देन परस्पर विरोधी लेनदेन को प्राप्त करके प्रसारित करने में विफल क्यों हुआ।

  • LDK #1401 शून्य-कॉन्फ़िगरेशन चैनल के लिए समर्थन जोड़ता है। संबंधित जानकारी के लिए, कृपया नीचे BOLTs #910 का सारांश देखें।

  • BOLTs #910 LN विनिर्देश को दो परिवर्तनों के साथ अद्यतन करता है। पहला शॉर्ट चैनल आइडेंटिफ़ायर (एससीआईडी) के लिए उपनामों को गोपनीयता में सुधार करने की अनुमति देता है। भले ही txid अस्थिर हो (यानी, जमा लेनदेन को विश्वसनीय संख्या में स्वीकृतियां मिलने से पहले) आपको चैनल ब्राउज़ करने की अनुमति देता है। दूसरा विनिर्देश परिवर्तन एक option_zeroconf फीचर बिट जोड़ता है जिसे तब सेट किया जा सकता है जब कोई नोड zero-conf channels का उपयोग करने के लिए तैयार हो।