diff --git a/_posts/hi/newsletters/2022-06-22-newsletter.md b/_posts/hi/newsletters/2022-06-22-newsletter.md
new file mode 100644
index 0000000000..176d2bc2f8
--- /dev/null
+++ b/_posts/hi/newsletters/2022-06-22-newsletter.md
@@ -0,0 +1,202 @@
+---
+title: 'Bitcoin Optech Newsletter #205'
+permalink: /hi/newsletters/2022/06/22/
+name: 2022-06-22-newsletter-hi
+slug: 2022-06-22-newsletter-hi
+type: newsletter
+layout: newsletter
+lang: hi
+---
+इस सप्ताह के समाचार पत्र में Bitcoin Core के लिए एक प्रस्तावित विकल्प का वर्णन किया गया है जो
+BIP125 में ऑप्ट-इन नहीं करने वाले लेनदेन के लिए भी लेनदेन प्रतिस्थापन को सक्षम करना आसान
+बना देगा, Hertzbleed साइडचैनल भेद्यता के बारे में जानकारी के लिंक, टाइम स्टैम्पिंग के बारे में चर्चा के
+निष्कर्ष को सारांशित करता है। सिस्टम डिज़ाइन, और एक नए एंटी-Sybil प्रोटोकॉल की जांच करता है जो
+Bitcoin UTXO का उपयोग करता है। Bitcoin क्लाइंट और सेवाओं में दिलचस्प नई सुविधाओं के
+विवरण, नए रिलीज और रिलीज उम्मीदवारों की घोषणा, और लोकप्रिय Bitcoin इंफ्रास्ट्रक्चर सॉफ्टवेयर
+में उल्लेखनीय परिवर्तनों के सारांश के साथ हमारे नियमित अनुभाग भी शामिल हैं।
+
+## समाचार
+
+- **<!--full-replace-by-fee:-->शुल्क द्वारा पूर्ण प्रतिस्थापन:** [दो][bitcoin core #25353] पुल [अनुरोध][bitcoin core #25373] को Bitcoin Core
+  में पूर्ण प्रतिस्थापन शुल्क के लिए समर्थन जोड़ने के लिए खोला गया है ([RBF][topic RBF]) एक विकल्प के रूप में जो डिफ़ॉल्ट
+  रूप से बंद है। यदि सक्षम किया गया है, तो उस नोड के mempool में किसी भी अपुष्ट लेनदेन को उस लेनदेन के वैकल्पिक संस्करण से बदला जा
+  सकता है जो उच्च शुल्क का भुगतान करता है (अन्य नियमों के बीच)।
+
+  वर्तमान में Bitcoin Core केवल RBF की अनुमति देता है यदि लेन-देन के संस्करण को
+  बदलने के लिए एक सिग्नलिंग बिट सक्षम है, जैसा कि [BIP125][] में परिभाषित किया गया है। यह
+  एलएन और [DLC][topic dlc] जैसे बहुपक्षीय अनुबंध प्रोटोकॉल के लिए एक चुनौती पैदा करता है, जहां
+  कभी-कभी एक पक्ष के लिए लेनदेन से BIP125 सिग्नल को हटाना संभव होता है ताकि अन्य पार्टियों को
+  लेनदेन प्रतिस्थापन का उपयोग करने से रोका जा सके। इससे देरी हो सकती है, और सबसे खराब
+  स्थिति में यह प्रोटोकॉल में धन की हानि का कारण बन सकता है जो समय पर पुष्टि पर निर्भर करता है
+  (जैसे कि [HTLCs][topic htlc] के लिए)।
+
+  [PRs में से एक][bitcoin core #25353] को जल्दी से महत्वपूर्ण डेवलपर समर्थन प्राप्त हुआ। क्योंकि यह केवल पूर्ण
+  RBF को सक्षम करने की क्षमता जोड़ता है --- लेकिन इसे डिफ़ॉल्ट रूप से सक्षम नहीं करता --- यह
+  Bitcoin Core के वर्तमान डिफ़ॉल्ट व्यवहार को नहीं बदलता है। लंबी अवधि में, कुछ डेवलपर्स
+  डिफ़ॉल्ट रूप से पूर्ण RBF को सक्षम करने की वकालत करेंगे, इसलिए सेवाओं, अनुप्रयोगों और
+  वैकल्पिक पूर्ण नोड के डेवलपर्स को देने के लिए इस सप्ताह Bitcoin-Dev मेलिंग सूची पर एक
+  धागा [शुरू किया गया][rbf discussion] था। सॉफ्टवेयर को एक पूर्ण RBF विकल्प प्रदान करने की दिशा के खिलाफ
+  बहस करने का मौका देता है और शायद अंततः इसे डिफ़ॉल्ट रूप से सक्षम करता है।
+
+- **Hertzbleed:** हाल ही में [खुलासा][hertzbleed] कई (शायद सभी) लोकप्रिय लैपटॉप, डेस्कटॉप और सर्वर सीपीयू प्रोसेसर को
+  प्रभावित करने वाली सुरक्षा भेद्यता हमलावरों को निजी कुंजी खोजने की अनुमति दे सकती है जब उन
+  कुंजियों का उपयोग Bitcoin के लिए हस्ताक्षर बनाने के लिए किया जा रहा हो। लेनदेन (या अन्य समान
+  संचालन करें)। इस हमले का उल्लेखनीय पहलू यह है कि यह हस्ताक्षर पीढ़ी कोड को प्रभावित कर
+  सकता है जो विशेष रूप से हमलावरों को जानकारी लीक होने से रोकने के लिए हमेशा एक ही प्रकार और
+  सीपीयू संचालन की संख्या का उपयोग करने के लिए लिखा गया था।
+
+  भेद्यता का शोषण करने के लिए एक हमलावर को या तो सीपीयू चिप की बिजली की खपत को मापने या
+  साइनिंग ऑपरेशन के कुछ हिस्सों की अवधि को मापने की आवश्यकता होगी। एक हमलावर के लिए
+  आदर्श रूप से, वे माप लेने में सक्षम होंगे, जबकि एक उपयोगकर्ता एक ही निजी कुंजी का उपयोग
+  करके कई हस्ताक्षर बनाता है। इस प्रकार, भेद्यता अक्सर उपयोग किए जाने वाले हॉट Wallet को
+  प्रभावित करने की अधिक संभावना है, जैसे कि होस्ट की गई सेवाओं और एलएन रूटिंग नोड्स द्वारा
+  उपयोग किए जाने वाले, और [पता पुन: उपयोग][topic output linking] के मामले। सुरक्षित वातावरण में उपयोग किए जाने
+  वाले अधिकतर या पूरी तरह से ऑफ़लाइन Wallet हमलों के लिए अधिक प्रतिरोधी होंगे।
+
+  इस लेखन के समय, यह पूरी तरह से स्पष्ट नहीं है कि Bitcoin उपयोगकर्ताओं के लिए भेद्यता
+  कितनी महत्वपूर्ण है। आज कई Wallet, जिनमें कई लोकप्रिय हार्डवेयर साइनिंग डिवाइस शामिल हैं,
+  पहले से ही सिग्नेचर जनरेशन कोड का उपयोग करने के लिए जाने जाते हैं जो पावर और टाइमिंग
+  विश्लेषण के लिए असुरक्षित है, इसलिए शायद उन उपयोगकर्ताओं के लिए कुछ भी नहीं बदला है।
+  अधिक सुरक्षित कोड वाले उपयोगकर्ताओं के लिए, यह संभव है कि डेवलपर्स अतिरिक्त सुरक्षा
+  लागू करेंगे। यदि आपके द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर के बारे में आपके कोई प्रश्न या चिंताएँ
+  हैं, तो कृपया उपयुक्त समर्थन चैनलों (जैसे [Bitcoin Stack Exchange][] के लिए कई मुफ़्त और ओपन
+  सोर्स सॉफ़्टवेयर Bitcoin प्रोजेक्ट्स के लिए) के माध्यम से इसके डेवलपर्स से संपर्क करें।
+
+- **<!--timestamping-design-->टाइमस्टैम्पिंग डिज़ाइन:** Bitcoin-आधारित [Open Timestamps][] (OTS) सिस्टम के डिज़ाइन के बारे
+  में Bitcoin-Dev मेलिंग सूची पर एक लंबी बहस इस सप्ताह [समापन][Poelstra Timestamping] लग रही थी। ऐसा प्रतीत होता है
+  कि बहस का स्रोत टाइम स्टैम्पिंग सिस्टम के लिए दो अलग-अलग डिज़ाइनों का अस्तित्व रहा है:
+
+    - *टाइम स्टैम्प्ड प्रूफ ऑफ एक्सिस्टेंस (TSPoE):* एक Bitcoin लेनदेन एक हैश डाइजेस्ट के लिए प्रतिबद्ध है जो
+      एक दस्तावेज़ के लिए प्रतिबद्ध है। जब किसी ब्लॉक में लेन-देन की पुष्टि हो जाती है, तो प्रतिबद्धता के
+      निर्माता के लिए तीसरे पक्ष को यह साबित करना संभव है कि दस्तावेज़ उस समय मौजूद था जब
+      ब्लॉक बनाया गया था। विशेष रूप से, हर बार स्टैम्पिंग ट्रांजैक्शन अन्य टाइम स्टैम्पिंग ट्रांजैक्शन से पूरी
+      तरह से स्वतंत्र हो सकता है, जिसका अर्थ है कि टाइम स्टैम्प के बीच कोई संबंध नहीं होने पर एक
+      ही दस्तावेज़ को कई बार टाइमस्टैम्प करना संभव है।
+
+    - *इवेंट ऑर्डरिंग (EO):* एक निर्दिष्ट तरीके से एक-दूसरे से संबंधित सभी लेन-देन की एक श्रृंखला
+      इस तरह से दस्तावेजों के लिए प्रतिबद्ध है कि सिस्टम के किसी भी उपयोगकर्ता को सभी
+      प्रतिबद्धताओं को देखने की अनुमति मिलती है। इस प्रणाली के तहत दो या अधिक बार
+      टाइमस्टैम्प किए गए किसी भी दस्तावेज़ के लिए, यह निर्धारित करना संभव है कि यह पहली
+      बार टाइमस्टैम्प किया गया था।
+
+  OTS द्वारा कार्यान्वित टीएसपीओई प्रणाली अनिवार्य रूप से पूरी तरह से कुशल है। यह
+  समय-समय पर असीमित संख्या में दस्तावेजों पर मुहर लगाने के लिए वैश्विक भंडारण स्थान की
+  समान मात्रा का उपयोग करता है, प्रत्येक व्यक्ति जो टाइमस्टैम्प का अनुरोध करता है, वह अपने
+  टाइम स्टैम्प प्रूफ को संग्रहीत करने के लिए जिम्मेदार होता है। इस प्रणाली को अवधारणा और
+  कार्यान्वयन दोनों में सरल होने का भी फायदा है।
+
+  EO प्रणाली के लिए आवश्यक है कि सभी पूर्ण प्रतिभागी प्रत्येक दस्तावेज़ के प्रति प्रतिबद्धताओं को
+  संग्रहित करें। यह बहुत कम कुशल हो सकता है और जटिलता जोड़ता है। ट्रेडऑफ़ यह है कि यह
+  प्रतिभागियों को यह सत्यापित करने की अनुमति देता है कि सिस्टम में पहली बार दस्तावेज़ कब
+  प्रकाशित किया गया था।
+
+  चर्चा ने किसी भी प्रणाली या प्रस्ताव में किसी भी घोषित परिवर्तन का नेतृत्व नहीं किया, जैसे कि ओपन
+  टाइमस्टैम्प या लेनदेन प्रायोजन (चर्चा का मूल विषय, [न्यूज़लेटर #116][news116 sponsorship] देखें)। यह कई चर्चा
+  प्रतिभागियों को आश्चर्यचकित करने वाला प्रतीत होता है कि उनमें से प्रत्येक की अलग-अलग
+  अवधारणाएं हो सकती हैं कि "टाइम स्टैम्पिंग" का क्या अर्थ है।
+
+- **नई RIDDLE एंटी-Sybil विधि:** Adam "Waxwing" Gibson [पोस्ट किया गया][gibson riddle post] Bitcoin-Dev मेलिंग सूची में
+  [एंटी-Sybil][sybil] के लिए एक [प्रस्ताव][gibson riddle gist] तंत्र जो Bitcoin UTXO सेट का उपयोग करता है और जो उचित रूप से अच्छी
+  गोपनीयता प्रदान कर सकता है। एक उपयोगकर्ता UTXO की एक सूची तैयार कर सकता है जहां
+  UTXO में से एक उपयोगकर्ता से संबंधित है और शेष अन्य उपयोगकर्ताओं से संबंधित है।
+  उपयोगकर्ता तब एक हस्ताक्षर बनाता है जो सूचीबद्ध UTXO में से एक के मालिक से आया है, लेकिन
+  यह नहीं बताता है कि इसे किस मालिक ने बनाया है।
+
+  एक दुर्भावनापूर्ण उपयोगकर्ता ऐसे कई सबूत उत्पन्न कर सकता है, लेकिन विकल्पों के पूल को
+  समाप्त करने से पहले उनमें से केवल एक सीमित संख्या में, दुर्लभ नेटवर्क संसाधनों को खत्म करने
+  की उनकी क्षमता को सीमित कर सकता है। दुर्भावनापूर्ण उपयोगकर्ता यथासंभव लंबे समय तक UTXO का
+  उपयोग कर सकते हैं और फिर इसे एक नया UTXO प्राप्त करने के लिए खर्च कर सकते हैं, लेकिन इसके
+  लिए एक लेनदेन शुल्क लगेगा। वह महँगाई भी दुरुपयोग को रोकती है। उपयोगकर्ता द्वारा चुने जाने
+  वाले UTXO को सीमित करके सेवाएँ Sybil को और सीमित कर सकती हैं। उदाहरण के लिए, एक सेवा केवल
+  UTXO पर एक हस्ताक्षर स्वीकार कर सकती है जो मूल्य में 1 बीटीसी है और जो एक वर्ष के लिए खर्च
+  नहीं किया गया है।
+
+  Gibson का प्रस्ताव है कि सदस्यता प्रमाण दो रूपों में आ सकते हैं। एक वैश्विक प्रमाण और एक स्थानीय
+  प्रमाण। वैश्विक प्रमाणों को सत्यापनकर्ताओं के बीच साझा किया जाएगा ताकि, आदर्श परिस्थितियों में, एक
+  उपयोगकर्ता वैश्विक संदर्भ में प्रति UTXO केवल एक प्रमाण बना सके। उदाहरण के लिए, उपयोगकर्ता
+  प्रत्येक वर्ष पुराने UTXO के लिए 1 BTC मूल्य के केवल एक खाते के लिए साइन अप करने में सक्षम होगा।
+
+  स्थानीय संदर्भ एकल सत्यापनकर्ता (या संबद्ध सत्यापनकर्ताओं का एक समूह, जैसे विकेन्द्रीकृत
+  विनिमय पर) के लिए विशिष्ट होंगे। उदाहरण के लिए, एक उपयोगकर्ता सेवा A पर API तक
+  पहुंचने के लिए UTXO का उपयोग कर सकता है और फिर सेवा B के लिए उसी UTXO का
+  पुन: उपयोग कर सकता है।
+
+  इसके अतिरिक्त, उच्च मूल्य वाले UTXO को कम मूल्य के कई UTXO के रूप में माना जा सकता है, इसलिए एक 10 BTC UTXO
+  उपयोगकर्ता को विभिन्न सेवाओं में 10 अलग-अलग खातों के लिए साइन अप करने की अनुमति दे
+  सकता है, जिनमें से प्रत्येक को वैश्विक संदर्भ में 1 BTC पूंजी की आवश्यकता होती है।
+
+  यद्यपि RIDDLE प्रोटोकॉल अन्य एंटी-Sybil तंत्रों पर गोपनीयता लाभ प्रदान करता है, Gibson चेतावनी देता
+  है कि सिस्टम के उपयोग की जानकारी को उपयोगकर्ता की गोपनीयता को संभावित रूप से कम करने के
+  लिए अन्य उपलब्ध जानकारी के साथ जोड़ा जा सकता है। वे लिखते हैं, "इस बात की कोई संभावना नहीं है कि
+  इस तरह की प्रणाली पक्की गोपनीयता की गारंटी प्रदान कर सकती है। यदि वास्तविक हस्ताक्षर
+  करने वाले यूटक्सो के स्थान की रक्षा करना जीवन और मृत्यु का मामला है, तो किसी भी तरह से इस तरह
+  की प्रणाली का उपयोग न करें!"
+
+  Lightning-Dev मेलिंग सूची में, डेवलपर ZmnSCPxj [सुझाया गया][zmnscpxj riddle] RIDDLE, LN के एंटी-Sybil तंत्र
+  को UTXO-आधारित चैनल पहचानकर्ताओं से अलग करने का एक विकल्प हो सकता है, जो [टैपरोट][topic taproot] और
+  [टैपरोट] के युग में है। हस्ताक्षर एकत्रीकरण [विषय संगीत], अनावश्यक रूप से खुलासा करें कि कौन से ऑन-चेन लेनदेन
+  एलएन चैनल खोलता है और आपसी बंद होता है।
+
+## सेवाओं और क्लाइंट सॉफ़्टवेयर में परिवर्तन
+
+*इस मासिक फीचर में, हम Bitcoin Wallet और सेवाओं के दिलचस्प अपडेट को हाइलाइट करते हैं।*
+
+- **Zeus Taproot सपोर्ट जोड़ता है:** [Zeus v0.6.5-rc1][] [Taproot][topic taproot] ​​जोड़ता है और LND v0.15+ बैकएंड के लिए समर्थन भेजता है।
+
+- **Wasabi Wallet 2.0 जारी:** यह [CoinJoin][topic coinjoin] सॉफ्टवेयर [रिलीज][Wasabi 2.0] अन्य सुधारों के साथ
+  [WabiSabi प्रोटोकॉल][News194 wabisabi] को लागू करता है।
+
+- **Sparrow Taproot हार्डवेयर साइनिंग जोड़ता है:** [HWI 2.1.0][] में अपग्रेड करके, Sparrow [1.6.4][Sparrow 1.6.4] कुछ हार्डवेयर साइनिंग डिवाइस
+  के लिए Taproot साइनिंग सपोर्ट जोड़ता है।
+
+## रिलीज और रिलीज उम्मीदवार
+
+* लोकप्रिय Bitcoin इन्फ्रास्ट्रक्चर परियोजनाओं के लिए नए रिलीज और रिलीज उम्मीदवार। कृपया नई
+रिलीज़ में अपग्रेड करने या रिलीज़ उम्मीदवारों का परीक्षण करने में मदद करने पर विचार करें।*
+
+- [LND 0.15.0-beta.rc6][] इस लोकप्रिय LN नोड के अगले प्रमुख संस्करण के लिए रिलीज़ उम्मीदवार है।
+
+- [LDK 0.0.108][] और 0.0.107 ऐसे रिलीज़ हैं जो मोबाइल की अनुमति देने वाले कोड प्रदान करने के अलावा [बड़े चैनल][topic large channels] और
+  [शून्य-कॉन्फ़ चैनल][topic zero-conf channels] के लिए समर्थन जोड़ते हैं। क्लाइंट एक सर्वर से नेटवर्क रूटिंग जानकारी (*gossip*), साथ
+  ही अन्य सुविधाओं और बग फिक्स को सिंक करने के लिए।
+
+- [BDK 0.19.0][] [Taproot][topic taproot] ​​के लिए [डिस्क्रिप्टर][topic descriptors], [पीएसबीटी][topic PSBT], और अन्य
+  उप-प्रणालियों के माध्यम से प्रयोगात्मक समर्थन जोड़ता है। यह एक नया [सिक्का चयन एल्गोरिथ्म][topic coin selection] भी जोड़ता है।
+
+## उल्लेखनीय कोड और दस्तावेज़ीकरण परिवर्तन
+
+*इस सप्ताह [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo],
+[LND][LND Repo] में उल्लेखनीय परिवर्तन। [libsecp256k1][libsecp256k1 repo], [हार्डवेयर Wallet इंटरफेस (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 GUI #602][] GUI में बदली गई सेटिंग्स को हेडलेस daemon (`bitcoind`) द्वारा लोड की
+  गई फाइल में लिखता है, इसलिए बदली गई सेटिंग्स का उपयोग किया जाता है, इससे कोई फर्क नहीं
+  पड़ता कि उपयोगकर्ता Bitcoin Core कैसे शुरू करता है।
+
+- [Eclair #2224][] Short Channel Identifier (scid) उपनाम और [ज़ीरो-कॉन्फ़ चैनल][topic zero-conf channels]
+  प्रकार का समर्थन जोड़ता है। scid उपनाम गोपनीयता में सुधार कर सकते हैं और पर्याप्त पुष्टि होने से पहले नोड्स के लिए चैनल को आसानी
+  से संदर्भित करना संभव बनाते हैं। ज़ीरो-कॉन्फ़ चैनल दो नोड्स को पर्याप्त रूप से पुष्टि होने से पहले भुगतान को रूट करने के लिए एक चैनल का
+  उपयोग करने के लिए सहमत होने की अनुमति देता है, जो कुछ प्रतिबंधों के तहत सुरक्षित हो सकता है।
+
+- [HWI #611][] BitBox02 हार्डवेयर साइनिंग डिवाइस के साथ [bech32m पतों][topic bech32] के लिए सिंगल-सिग सपोर्ट जोड़ता है।
+
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="602,2224,611,25353,25373" %}
+[lnd 0.15.0-beta.rc6]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc6
+[ldk 0.0.108]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.108
+[bdk 0.19.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.19.0
+[rbf discussion]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
+[hertzbleed]: https://www.hertzbleed.com/
+[news116 sponsorship]: /en/newsletters/2020/09/23/#transaction-fee-sponsorship
+[poelstra timestamping]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020569.html
+[gibson riddle post]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020555.html
+[gibson riddle gist]: https://gist.github.com/AdamISZ/51349418be08be22aa2b4b469e3be92f
+[bitcoin stack exchange]: https://bitcoin.stackexchange.com/
+[open timestamps]: https://opentimestamps.org/
+[sybil]: https://en.wikipedia.org/wiki/Sybil_attack
+[zmnscpxj riddle]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003607.html
+[Zeus v0.6.5-rc1]: https://github.com/ZeusLN/zeus/releases/tag/v0.6.5-rc1
+[wasabi 2.0]: https://github.com/zkSNACKs/WalletWasabi/releases/tag/v2.0.0.0
+[news194 wabisabi]: /en/newsletters/2022/04/06/#wabisabi-alternative-to-payjoin
+[HWI 2.1.0]: /en/newsletters/2022/03/23/#hwi-2-1-0-rc-1
+[sparrow 1.6.4]: https://github.com/sparrowwallet/sparrow/releases/tag/1.6.4
\ No newline at end of file