diff --git a/_posts/hi/newsletters/2022-06-15-newsletter.md b/_posts/hi/newsletters/2022-06-15-newsletter.md
new file mode 100644
index 0000000000..22d3509188
--- /dev/null
+++ b/_posts/hi/newsletters/2022-06-15-newsletter.md
@@ -0,0 +1,242 @@
+---
+title: 'Bitcoin Optech Newsletter #204'
+permalink: /hi/newsletters/2022/06/15/
+name: 2022-06-15-newsletter-hi
+slug: 2022-06-15-newsletter-hi
+type: newsletter
+layout: newsletter
+lang: hi
+---
+इस सप्ताह का समाचार पत्र Bitcoin P2P नेटवर्क में पैकेज रिले को जोड़ने के बारे में जारी चर्चा को
+सारांशित करता है, हाल ही में LN डेवलपर्स मीटिंग का सारांश साझा करता है, और एक तर्क का वर्णन
+करता है कि LN पर खर्च करने वाले और रूटिंग नोड्स कैसे विश्वसनीयता और कम शुल्क दोनों के
+लिए अनुकूलित कर सकते हैं। दोनों समूहों को लाभ। हालिया रिलीज और रिलीज उम्मीदवारों के सारांश के
+साथ-साथ लोकप्रिय Bitcoin इंफ्रास्ट्रक्चर सॉफ्टवेयर में उल्लेखनीय बदलाव के साथ हमारे नियमित
+अनुभाग भी शामिल हैं।
+
+## समाचार
+
+- **निरंतर पैकेज रिले BIP चर्चा:** [पैकेज रिले][topic package relay] के लिए हाल ही में एक मसौदा
+  BIP (देखें [Newsletter #201][news201 relay]) को पिछले कई हफ्तों में अतिरिक्त टिप्पणियां मिली हैं:
+
+    - *<!--policy-limits-->नीति सीमाएं:* Anthony Towns [पूछे गए][towns relay] यदि पैकेज रिले का समर्थन करने के लिए दो
+      साथियों के बीच बातचीत में प्रत्येक सहकर्मी के पैकेज के बारे में अधिकतम आकार और गहराई
+      सीमा के बारे में जानकारी शामिल होनी चाहिए, अन्यथा गैर-डिफ़ॉल्ट सेटिंग्स वाले नोड्स को इसके बारे
+      में बार-बार सूचनाएं प्राप्त हो सकती हैं। वे पैकेज जो वे नहीं चाहते थे, बैंडविड्थ बर्बाद कर रहे
+      थे। BIP लेखिका Gloria Zhao [सुझाव देती हैं][zhao negotiation] पैकेज रिले प्रोटोकॉल के पहले संस्करण
+      का उपयोग करते हुए अधिकतम 25 लेनदेन और 101,000 vbytes का पैकेज आकार होना चाहिए।
+
+    - *<!--package-graph-announcement-only-->केवल पैकेज ग्राफ घोषणा:* Eric Voskuil [सिफारिश करता है][voskuil graph] कि एक सहकर्मी जो
+      कम-फीट पूर्वज के उच्च-फीट वंशज के बारे में सीखता है, उसे अपने साथियों को उन दो लेनदेन
+      के बीच संबंधों के बारे में सूचित करना चाहिए, जिन्हें पैकेज ग्राफ कहा जाता है। एक प्राप्त करने वाला
+      सहकर्मी तब किसी भी लेनदेन का अनुरोध कर सकता है जो उसके पास नहीं है। धागे के एक
+      अलग हिस्से में, Towns [नोट्स][towns graph] कि एक ग्राफ को तब तक मान्य नहीं किया जा सकता है जब
+      तक कि सभी लेनदेन प्राप्त नहीं हो जाते हैं, इसलिए यह सुनिश्चित करने के लिए ध्यान रखा जाना
+      चाहिए कि एक सहकर्मी ग्राफ के बारे में झूठ नहीं बोल सकता है। लेन-देन को अन्य साथियों द्वारा रिले
+      किए जाने से रोकें।
+
+    - *<!--using-short-ids-->लघु आईडी का उपयोग करना:* कई डेवलपर्स ने [BIP152][]-शैली के लघु पहचानकर्ताओं (आईडी)
+      का उपयोग करने का सुझाव दिया। झाओ [समझाया][zhao sids] कि छोटी आईडी ब्लॉक रिले के लिए समझ
+      में आती है जहां नोड्स पहले एक नए ब्लॉक के काम के सबूत (जो बनाने के लिए महंगा है) को मान्य
+      करते हैं, इसलिए एक हमलावर के लिए नोड संसाधनों को बर्बाद करने के लिए तंत्र का
+      दुरुपयोग करना महंगा होगा। लेकिन, डेटा के रिले के लिए जो बनाने के लिए सस्ता है, शॉर्ट आईडी का
+      बार-बार दुरुपयोग किया जा सकता है ताकि संभावित रूप से सेवा से इनकार किया जा सके।
+
+    - *<!--non-standard-parents-->गैर-मानक माता-पिता:* Suhas Daftuar [वर्णन][daftuar repeat] एक परिदृश्य जहां एक नोड
+      कार्यान्वयन पैकेज रिले एक ही डेटा का बार-बार अनुरोध कर सकता है। यह विशेष रूप से तब
+      होने की संभावना है जब रिले नीति पुराने और नए नोड्स के बीच भिन्न होती है, जैसे कि सॉफ्ट फोर्क
+      सक्रिय होने के बाद।
+
+    - *<!--challenges-of-a-block-hash-beacon-->ब्लॉक हैश बीकन की चुनौतियाँ:* Daftuar यह भी नोट करता है कि प्रस्ताव की एक विशेषता अन्य सॉफ़्टवेयर के
+      लिए समस्याएँ पैदा कर सकती है। वर्तमान मसौदा BIP में प्रत्येक पैकेज घोषणा में ब्लॉक
+      श्रृंखला पर नवीनतम ब्लॉक के नोड का वर्तमान हैश शामिल है। यह प्राप्त करने वाले सहकर्मी को
+      किसी पैकेज को अनदेखा करने की अनुमति देता है यदि यह पहले के ब्लॉक (या वैकल्पिक श्रृंखला) से
+      है, तो इस स्थिति में पैकेज प्राप्त करने वाले सहकर्मी के वर्तमान मेमपूल के साथ काम नहीं कर
+      सकता है। हालाँकि, Daftuar नोट करता है कि संभवतः बहुत सारे सॉफ़्टवेयर हैं जो लेन-देन भेजते हैं --- और
+      जो अंततः पैकेज भेजना पसंद कर सकते हैं --- जो वर्तमान श्रृंखला टिप हैश का ट्रैक नहीं रखता है।
+
+- **LN डेवलपर मीटिंग का सारांश:** Olaoluwa Osuntokun ने पिछले सप्ताह Oakland में LN देव मीटिंग का [विस्तृत सारांश][osuntokun summary] प्रदान किया।
+  शामिल विषयों में शामिल हैं:
+
+    - *Taproot-आधारित LN चैनल:* प्रतिभागियों ने LN को [Taproot]​​[topic taproot]
+      ​​सुविधाओं के पूर्ण उपयोग के लिए ले जाने के लिए पहले चरणों पर चर्चा की। बाद के चरणों में
+      [PTLCs][topic ptlc] के लिए समर्थन शामिल होने की संभावना है (यह भी देखें
+      [Newsletter #164][news164 taproot ln])।
+
+    - *TapScript और MuSig2:* Taproot-आधारित चैनलों पर स्विच के हिस्से के रूप में, मौजूदा स्क्रिप्ट को
+      टैपस्क्रिप्ट में बदलने की आवश्यकता है जिससे ब्लॉक स्पेस का सबसे कुशल उपयोग हो सके। उन
+      सभी जगहों पर हस्ताक्षर बनाने के लिए [MuSig2][topic musig] का उपयोग करने की भी इच्छा है
+      जहां दोनों हस्ताक्षरकर्ताओं से सहयोगात्मक रूप से कार्य करने की उम्मीद की जाती है। यह
+      सुनिश्चित करने के लिए कि वे अपेक्षित रूप से काम करते हैं, इन दोनों को लागू करने और
+      परीक्षण करने की आवश्यकता है।
+
+    - *Recursive MuSig2:* MuSig2 का एक सरल कार्यान्वयन ऐलिस और बॉब को संयुक्त रूप से एकल
+      हस्ताक्षर बनाने की अनुमति दे सकता है। रिकर्सिव Musig2, उदाहरण के लिए, ऐलिस को अपने हॉट वॉलेट
+      और हार्डवेयर साइनिंग डिवाइस दोनों का उपयोग करके बॉब के बिना कोई विशेष कदम उठाए या यहां तक ​​​​कि
+      यह जानते हुए भी कि ऐलिस एक से अधिक कुंजी के साथ हस्ताक्षर कर रहा था, हस्ताक्षर का अपना
+      हिस्सा बनाने की अनुमति देगा। यह चर्चा की गई कि LN के MuSig2 के उपयोग को कैसे
+      डिजाइन किया जाए ताकि यह सुनिश्चित हो सके कि रिकर्सिव Musig2 उपलब्ध था। साथ ही पुनरावर्ती MuSig2
+      की सुरक्षा पर भी चर्चा की गई।
+
+    - *Extension BOLTs* LN प्रोटोकॉल विनिर्देश में परिवर्तन निर्दिष्ट करने का एक वैकल्पिक तरीका।
+      वर्तमान में, विनिर्देश में परिवर्तन मौजूदा विनिर्देश के पैच (diff) के रूप में किए जाते हैं। हालांकि, कुछ
+      डेवलपर्स BIP के लिए इस्तेमाल की जाने वाली विधि को पसंद करते हैं जहां प्रोटोकॉल में बड़े
+      बदलाव उन परिवर्तनों के लिए विशिष्ट एक या अधिक दस्तावेजों में निर्दिष्ट होते हैं। उन
+      डेवलपर्स का मानना ​​​​है कि अलग-अलग दस्तावेज़ लिखना और पढ़ना आसान है, और इसलिए
+      विकास को सरल और तेज कर सकते हैं।
+
+    - *<!--gossip-network-updates-->गॉसिप नेटवर्क अपडेट:* बैठक ने LN गपशप को अद्यतन करने के बारे में मौजूदा
+      चर्चा जारी रखी (देखें [Newsletter #188][news188 gossip]), जिसका उपयोग नए और अपडेट किए गए
+      चैनलों के बारे में घोषणाओं को रिले करने के लिए किया जाता है। सारांश के अनुसार, प्रतिभागी
+      MuSig2-आधारित Taproot चैनलों का समर्थन करने के लिए प्रोटोकॉल के एक छोटे से उन्नयन
+      पर अल्पावधि में ध्यान केंद्रित करना पसंद करेंगे और [TLV][news55 tlv] शब्दार्थ का पूरी
+      तरह से उपयोग करने के लिए प्रोटोकॉल को अपग्रेड करेंगे।
+
+    - *Minisketch-आधारित कुशल गपशप:* जैसा कि [Newsletter #198][news198 minisketch]
+      में उल्लेख किया गया है, नोड्स के बीच LN गॉसिप को सिंक करने के लिए उपयोग की जाने वाली बैंडविड्थ की मात्रा को कम
+      करने के लिए [minisketch][topic minisketch] का उपयोग करने के लिए अनुसंधान जारी है, जो हो
+      सकता है अद्यतनों के बीच न्यूनतम अनुमत समय को कम करने की भी अनुमति देता है।
+
+    - *अनियन संदेश DoS:* कई LN कार्यान्वयन पहले से ही [अनियन संदेश][topic onion messages] का समर्थन करते हैं,
+      संदेश भेजने के लिए [keysend][topic spontaneous payments] भुगतान का उपयोग करने के विकल्प के
+      रूप में और प्रस्तावित [BOLT12 ऑफ़र प्रोटोकॉल के लिए संचार परत के रूप में][topic offers]। हालाँकि, जैसा कि
+      [Newsletter #190][news190 onion] में उल्लेख किया गया है, कुछ डेवलपर्स चिंतित रहते हैं कि onion संदेश
+      कई अलग-अलग प्रकार के सेवा से इनकार करने वाले हमलों के प्रति संवेदनशील हो सकते हैं। DoS
+      हमलों को रोकने के कई तरीकों पर चर्चा की गई।
+
+    - *<!--blinded-paths-->ब्लाइंड  हुए रास्ते:* कई साल पहले प्रस्तावित एक तकनीक (देखें [Newsletter #85][news85 blinded])
+      और अब अनियन  संदेशों के लिए उपयोग किया जाता है, उपयोगकर्ताओं को अपनी पहचान का खुलासा किए बिना
+      भुगतान प्राप्त करने की अनुमति देने के लिए नियमित भुगतान के साथ प्रयोग के लिए प्रयोग भी
+      देखा जा रहा है। उनके LN नोड। इस दृष्टिकोण के सामने एक चुनौती यह है कि इसके लिए
+      अधिक रूटिंग जानकारी संप्रेषित करने की आवश्यकता होती है, इसलिए बड़े चालानों की
+      आवश्यकता होती है। यह नए इनवॉइस-प्रबंधन प्रोटोकॉल जैसे कि BOLT12 ऑफ़र या [LNURL][] पर निर्भर ब्लाइंड
+      रास्तों का प्रभावी कार्यान्वयन कर सकता है। कई अन्य चिंताओं पर भी चर्चा की गई।
+
+    - *<!--probing-and-balance-sharing-->जांच और संतुलन साझा करना:* विभिन्न तकनीकों का उपयोग करके, एक नोड के लिए नेटवर्क
+      पर चैनलों के संतुलन की *जांच* करना संभव है। जांच करने वाले नोड के लिए इस तरह की जांच
+      प्रभावी रूप से मुफ्त है लेकिन यह गोपनीयता को कम करने के अलावा नेटवर्क के नियमित
+      उपयोगकर्ताओं के लिए समस्या पैदा कर सकती है। अलग [चैनल जैमिंग अटैक][topic channel jamming attacks]
+      के लिए शमन जांच को सीमित करने में मदद कर सकता है, लेकिन यह वर्तमान
+      समय में एक चिंता का विषय बना हुआ है, इसलिए प्रतिभागियों ने नोड सेटिंग्स में कुछ त्वरित
+      परिवर्तनों पर चर्चा की जो जांच को और अधिक कठिन बना सकते हैं।
+
+      इसके अतिरिक्त, एक पहले से चर्चित विचार प्रयोग यह है कि एक जांच नोड सीखेगा
+      और बिना किसी जांच की आवश्यकता के इसे स्वतंत्र रूप से साझा करेगा। यदि यह प्रत्येक नोड
+      द्वारा किया जाता है, तो बैंडविड्थ की आवश्यकताएं और गोपनीयता की हानि LN के प्रमुख
+      लाभों को नकार देगी --- लेकिन यह रूटिंग भुगतान को और अधिक कुशल बना देगी। कोई भी उस
+      विचार का प्रस्ताव नहीं कर रहा है, लेकिन पिछले शोध विषय पर चर्चा की गई थी कि प्रत्येक
+      नोड केवल अपने प्रत्यक्ष चैनल साथियों के साथ साझा कर रहा था, कुछ जानकारी जो वे जांच के
+      माध्यम से सीख सकते थे। यह दावा किया गया था कि यह भुगतान रूटिंग सफलता में काफी
+      सुधार कर सकता है, जैसे कि [जस्ट-इन-टाइम (जेआईटी) चैनल रीबैलेंसिंग][topic jit routing]
+      को पूरक करके।
+
+    - *<!--trampoline-routing-and-mobile-payments-->ट्रैम्पोलिन रूटिंग और मोबाइल भुगतान:* [ट्रैम्पोलिन रूटिंग][topic trampoline payments] एक स्पेंडर
+      को नेटवर्क पर किसी अन्य नोड के लिए पाथफाइंडिंग को आउटसोर्स करने की अनुमति देता है,
+      वैकल्पिक रूप से इस तरह से जो किसी भी मध्यवर्ती नोड को नेटवर्क पहचान सीखने से रोकने के
+      लिए LN की सामान्य गोपनीयता बनाए रखता है। या तो खर्च करने वाला या पाने वाला। यह
+      आउटसोर्सिंग उन मोबाइल LN ग्राहकों के लिए विशेष रूप से उपयोगी है जो अन्य नोड्स के
+      लिए अन्य भुगतानों को रूट करने का प्रयास नहीं कर रहे हैं। जैसा कि मीटिंग सारांश में बताया गया
+      है, ट्रैम्पोलिन भुगतानों को *फर्स्ट हॉप पेमेंट होल्ड* के साथ जोड़ा जा सकता है
+      (देखें [Newsletter #171][news171 ln offline]) जहां भुगतान प्राप्तकर्ता के सीधे चैनल
+      पीयर द्वारा तब तक आयोजित किया जाता है जब तक कि प्राप्तकर्ता नोड अगला ऑनलाइन न हो।
+      अक्सर-ऑफ़लाइन मोबाइल नोड को अन्य अक्सर-ऑफ़लाइन मोबाइल नोड्स से विश्वसनीय रूप से
+      भुगतान प्राप्त करने की अनुमति देता है।
+
+    - *LNURL plus BOLT12:* LNURL प्रोटोकॉल एक नोड को वेबसर्वर से [BOLT11][] इनवॉइस का
+      अनुरोध करने की अनुमति देता है; BOLT12 [ऑफ़र्स][topic offers] प्रोटोकॉल नेटवर्क पर एक नोड
+      से इनवॉइस का अनुरोध करने की अनुमति देता है। इन प्रोटोकॉल के अन्य पहलुओं में, प्रतिभागियों ने
+      चर्चा की कि कैसे दो प्रोटोकॉल को एक-दूसरे के साथ संगत बनाया जा सकता है ताकि नोड्स दोनों में
+      से किसी एक या दोनों का उपयोग कर सकें।
+
+- **<!--using-routing-fees-to-signal-liquidity-->तरलता का संकेत देने के लिए रूटिंग शुल्क का उपयोग करना:** डेवलपर ZmnSCPxj [पोस्ट किया गया][zmnscpxj hilolohi] Lightning-देव
+  मेलिंग सूची में एक तर्क है कि कैसे खर्च करने वालों और रूटिंग नोड्स के बीच गेम थ्योरेटिक व्यवहार के
+  माध्यम से बेहतर सस्ते और विश्वसनीय भुगतान प्राप्त किए जा सकते हैं:
+
+    - खर्च करने वालों को उन रास्तों का चयन करना चाहिए जो रूटिंग शुल्क में कम शुल्क लेते हैं।
+
+    - रूटिंग नोड्स को चैनल का उपयोग करने के लिए अधिक चार्ज करना चाहिए क्योंकि इसकी क्षमता
+      घट जाती है। उदाहरण के लिए, यदि चैनल में अधिकांश शेष राशि ऐलिस के स्वामित्व में है, तो वह
+      विश्वसनीय रूप से बॉब को भुगतान अग्रेषित कर सकती है और इसलिए उसे अधिक शुल्क
+      नहीं लेना चाहिए; लेकिन, जैसे-जैसे अधिक शेष राशि बॉब की ओर अग्रेषित की जाती है, ऐलिस की
+      अतिरिक्त भुगतान अग्रेषित करने की क्षमता कम हो जाती है, इसलिए उसे अधिक शुल्क लेना चाहिए।
+
+  ZmnSCPxj आपूर्ति और मांग अर्थशास्त्र का उपयोग करके इस तर्क को फ्रेम करता है --- जैसे-जैसे एक दिशा में
+  भुगतान को रूट करने की मांग बढ़ती है, उदा। ऐलिस से बॉब तक, अतिरिक्त सतोशी की आपूर्ति जो उस
+  दिशा में रूट की जा सकती है, स्वाभाविक रूप से कम हो जाती है। रूटिंग शुल्क की कीमत बढ़ाने से मांग कम हो
+  सकती है जब तक कि दूसरी दिशा में भुगतान करने वाले लोगों के माध्यम से आपूर्ति फिर से बढ़ जाती है
+  (जैसे बॉब से ऐलिस तक)।
+
+  खर्च करने वालों को पहले से ही स्वाभाविक रूप से कम शुल्क (अन्य सभी चीजें समान होने) का उपयोग करने
+  के लिए प्रोत्साहित किया जाता है, इसलिए ZmnSCPxj का तर्क है कि कोई भी रूटिंग नोड जो उच्च-आपूर्ति/कम-शुल्क
+  और कम-आपूर्ति/उच्च-शुल्क की रणनीति को अपनाता है, स्वचालित रूप से अपने चैनलों को उचित
+  रूप से बनाए रखेगा संतुलित और इसलिए इस रणनीति को अपनाने वाले नोड्स की तुलना में अपने
+  चैनल के जीवनकाल में अधिक से अधिक सफल भुगतान संसाधित करने में सक्षम हो। क्योंकि रूटिंग
+  नोड्स को केवल सफल भुगतान रूटिंग के लिए भुगतान मिलता है, यह उच्च-निम्न/निम्न-उच्च
+  रणनीति को अपनाने वाले नोड्स को अधिक प्रतिस्पर्धी बना सकता है।
+
+  इस दृष्टिकोण का एक प्रमुख लाभ यह है कि यह खर्च करने वालों के लिए रास्ता खोजना बहुत आसान
+  बनाता है --- वे केवल क्षमता सीमा के भीतर सबसे सस्ते मार्गों पर भुगतान करने का प्रयास करते हैं।
+  एक कमी यह है कि उच्च-निम्न/निम्न-उच्च रणनीति के तहत रूटिंग नोड्स शुल्क में प्रत्येक
+  परिवर्तन चैनल के संतुलन में एक समान परिवर्तन का अर्थ है, भुगतान के आकार के बारे में
+  जानकारी का खुलासा करना जो हाल ही में उस चैनल में प्रवाहित हो सकता है। उदाहरण के लिए, यदि
+  चैनल एलिस → बॉब, बॉब → कैरल, और कैरल → डैन सभी हाल ही में क्षमता में लगभग 1 BTC कम हो गए
+  हैं, तो यह अनुमान लगाना उचित है कि ऐलिस या उसके किसी चैनल पार्टनर ने डैन को 1 BTC
+  भुगतान किया है या उनके चैनल भागीदारों में से एक। एक अतिरिक्त समस्या यह है कि चैनल की फीस
+  में प्रत्येक परिवर्तन को पूरे नेटवर्क में गपशप करने की आवश्यकता होती है, जो बैंडविड्थ
+  आवश्यकताओं को बढ़ाता है और जो नकली रूटिंग विफलताओं का कारण बन सकता है (उदाहरण के
+  लिए क्योंकि स्पेंडर सैली ने ऐलिस के नए उच्च शुल्क के बारे में नहीं सुना है और इसलिए रूटिंग का
+  प्रयास करता है एलिस से बॉब को पुराने और कम शुल्क का उपयोग करके पूरे चैनल में भुगतान
+  जिसे एलिस अस्वीकार कर देता है)।
+
+  ZmnSCPxj कई शमन रणनीतियों का वर्णन करके इन मुद्दों को संबोधित करता है, जिनमें से कुछ को नोड्स द्वारा
+  अब LN प्रोटोकॉल में कोई बदलाव नहीं किया जा सकता है, और जिनमें से कुछ को LN गॉसिप
+  प्रोटोकॉल में मामूली अपडेट की आवश्यकता होगी। वर्णित शमन रणनीतियों को इस लेखन के रूप में
+  मेलिंग सूची पर कोई चर्चा नहीं मिली है, हालांकि LN डेवलपर की बैठक के ओलाओलुवा
+  ओसुंटोकुन के सारांश में उनका उल्लेख किया गया है (जैसा कि पिछले बुलेट बिंदु में ऑप्टेक द्वारा आगे
+  संक्षेप में बताया गया है)।
+
+## रिलीज और रिलीज उम्मीदवार
+
+* लोकप्रिय Bitcoin इन्फ्रास्ट्रक्चर परियोजनाओं के लिए नए रिलीज और रिलीज उम्मीदवार। कृपया नई
+रिलीज़ में अपग्रेड करने या रिलीज़ उम्मीदवारों का परीक्षण करने में मदद करने पर विचार करें।*
+
+- [LND 0.15.0-beta.rc6][] इस लोकप्रिय LN नोड के अगले प्रमुख संस्करण के लिए रिलीज़ उम्मीदवार है।
+
+## उल्लेखनीय कोड और दस्तावेज़ीकरण परिवर्तन
+
+*इस सप्ताह [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo],
+[Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo] में उल्लेखनीय परिवर्तन।
+[libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo],
+[Rust Bitcoin][rust bitcoin repo], [BTCPay server][btcpay server repo], [BDK][bdk repo],
+[Bitcoin Improvement Proposals（BIP)][bips repo], और [Lightning BOLTs][bolts repo]।*
+
+- [Bitcoin Core #24171][] इनबाउंड पीयर्स से ब्लॉक डेटा का अनुरोध करने के लिए प्रारंभिक ब्लॉक डाउनलोड
+  (आईबीडी) व्यवहार में संशोधन करता है यदि कोई आउटबाउंड पीयर ब्लॉक डेटा की सेवा नहीं कर रहा है।
+  पहले, एक नोड केवल इनबाउंड पीयर से डेटा का अनुरोध करेगा यदि उसके पास कोई आउटबाउंड
+  पीयर नहीं था। यह व्यवहार एक स्टाल का कारण बन सकता है यदि नोड में केवल आउटबाउंड पीयर थे
+  जो ब्लॉक की सेवा नहीं करते थे। जैसे ही कोई आउटबाउंड पीयर ब्लॉक की सेवा करता है, नोड्स अभी भी केवल
+  आउटबाउंड पीयर से डेटा का अनुरोध करते हैं।
+
+- [BDK #593][] [rust bitcoin][Rust Bitcoin repo] 0.28 का उपयोग करना शुरू करता है, जिसमें [Taproot][topic taproot]
+  और Taproot [आउटपुट स्क्रिप्ट डिस्क्रिप्टर][topic descriptors] के लिए समर्थन शामिल है।
+
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="24171,1505,628,593" %}
+[lnd 0.15.0-beta.rc6]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc6
+[news201 relay]: /en/newsletters/2022/05/25/#package-relay-proposal
+[towns relay]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020496.html
+[zhao negotiation]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020512.html
+[voskuil graph]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020518.html
+[towns graph]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020520.html
+[zhao sids]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020539.html
+[daftuar repeat]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020542.html
+[osuntokun summary]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003600.html
+[news164 taproot ln]: /en/newsletters/2021/09/01/#preparing-for-taproot-11-ln-with-taproot
+[news188 gossip]: /en/newsletters/2022/02/23/#updated-ln-gossip-proposal
+[news55 tlv]: /en/newsletters/2019/07/17/#bolts-607
+[news198 minisketch]: /en/newsletters/2022/05/04/#ln-gossip-rate-limiting
+[news190 onion]: /en/newsletters/2022/03/09/#paying-for-onion-messages
+[news85 blinded]: /en/newsletters/2020/02/19/#decoy-nodes-and-lightweight-rendez-vous-routing
+[lnurl]: https://github.com/fiatjaf/lnurl-rfc
+[news171 ln offline]: /en/newsletters/2021/10/20/#paying-offline-ln-nodes
+[zmnscpxj hilolohi]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html