Submarine Swap से आप ब्लॉकचेन पर मौजूद अपने बिटकॉइन का इस्तेमाल करके Lightning Network के ज़रिए भुगतान कर सकते हैं। ब्लॉकचेन बिटकॉइन के लेनदेन का सार्वजनिक इतिहास है। Lightning हर भुगतान को इस इतिहास में अलग से दर्ज किए बिना तेज़ भुगतान की सुविधा देता है। उल्टी दिशा को Reverse Submarine Swap कहते हैं। आप दूसरी मुद्रा नहीं खरीदते; शुल्क कटने के बाद पैसे को भुगतान के इन दो तरीकों के बीच ले जाते हैं। क्रिप्टोग्राफ़िक और समय से जुड़ी शर्तें दोनों भुगतानों को जोड़ती हैं। ऐप को इनकी जाँच करके समय रहते अदला-बदली पूरी करनी होती है या पैसे वापस लेने की प्रक्रिया चलानी होती है।
अन्ना साधारण वॉलेट में बिटकॉइन रखती हैं, लेकिन दुकान उन्हें Lightning इनवॉइस, यानी भुगतान का अनुरोध देती है। सामान्य स्वैप में तय शर्तों के तहत ब्लॉकचेन पर बिटकॉइन लॉक किए जाते हैं और बदले में सेवा इनवॉइस का भुगतान करती है। Lightning का शेष ब्लॉकचेन के पते पर ले जाने के लिए उल्टा रास्ता चाहिए: Reverse Submarine Swap, जैसे Loop Out। अपने भुगतान चैनल बंद करना ज़रूरी नहीं। इससे नया पैसा नहीं बनता और Lightning भुगतान के लिए उपलब्ध रास्ता फिर भी चाहिए। [1] [4]
एक ऐसे रहस्य की कल्पना करें जिसकी डिजिटल छाप जाँची जा सके, लेकिन छाप से रहस्य वापस निकालना व्यावहारिक रूप से संभव न हो। इस गुप्त मान को preimage कहते हैं। इसकी डिजिटल छाप hash, यानी हैश है, जिसकी गणना SHA256 से होती है। HTLC नाम के शर्त वाले भुगतान इस छाप को समय-सीमा से जोड़ते हैं। उल्टे स्वैप में अन्ना का ऐप रहस्य बनाता है। सेवा उनका Lightning भुगतान लंबित रखती है और बराबर के बिटकॉइन ब्लॉकचेन पर लॉक करती है। claim, यानी पैसे लेने की प्रक्रिया में अन्ना रहस्य ब्लॉकचेन पर दिखाती हैं या सहयोग के दौरान सेवा को देती हैं। तब सेवा जुड़ा हुआ भुगतान निपटा सकती है। लंबित होना भुगतान पूरा होना नहीं है। [1] [4]
सेवा की सूचना और गंतव्य वॉलेट में पैसे आना अलग बातें हैं। Boltz के अनुसार उल्टे स्वैप में invoice.settled, preimage दिए जाने और Lightning इनवॉइस के निपटारे के बाद दिख सकता है। सेवा यह नहीं देखती कि अन्ना के ऐप ने claim लेनदेन वास्तव में प्रसारित किया या नहीं। इसलिए गंतव्य आउटपुट, यानी उनके वॉलेट को निर्धारित बिटकॉइन का हिस्सा, और आवश्यक ब्लॉक पुष्टियाँ जाँचनी चाहिए। ब्लॉक लेनदेन का एक समूह है जो ब्लॉकचेन में जुड़ता है। किसी लेनदेन को ब्लॉक में शामिल करने पर उसकी पहली पुष्टि होती है। उसके बाद जुड़ने वाला हर ब्लॉक एक और पुष्टि जोड़ता है। अस्पष्ट स्थिति देखकर तुरंत वही भुगतान दोबारा भेजना ठीक नहीं। [1] [2]
सामान्य स्वैप में अन्ना के बिटकॉइन ब्लॉकचेन पर लॉक हो सकते हैं, जबकि इनवॉइस अब भी अवैतनिक हो। तब refund, धन-वापसी, के लिए ऐप को लेनदेन बनाकर प्रसारित करना पड़ता है। सेवा साथ न दे तो तय समय की शर्त timelock पूरी होने का इंतज़ार करना होगा। उल्टी दिशा में अनिपटाए Lightning भुगतान के लंबित HTLC रद्द हो सकते हैं और अन्ना के ऑन-चेन refund लेनदेन के बिना शेष मुक्त हो सकता है। लेकिन preimage खुलने के बाद निपट चुका भुगतान अपने-आप वापस नहीं आता। दिशा और मौजूदा चरण मायने रखते हैं। [1] [3]
अन्ना भेजी गई राशि की तुलना वास्तव में आई राशि से करती हैं। अंतर में सेवा शुल्क, Lightning रूटिंग और ब्लॉकचेन लेनदेन शुल्क शामिल हो सकते हैं। असफल सामान्य स्वैप में धन-वापसी के लेनदेन का शुल्क भी जुड़ सकता है। समय भी अहम है: प्रकाशित claim ब्लॉक पुष्टि से पहले preimage खोल सकता है। Loop के दस्तावेज़ बताते हैं कि timeout पास आने पर ग्राहक प्रोग्राम, पैसे लेने वाले sweep लेनदेन का शुल्क शुरुआती सीमा से ऊपर बढ़ा सकता है। इसलिए क्रिप्टोग्राफ़िक संबंध तुरंत, मुफ़्त या जोखिमरहित अदला-बदली का वादा नहीं है। [5] [6]
दूसरे वॉलेट के पुनर्प्राप्ति शब्द चल रहे स्वैप को वापस लाने के लिए पर्याप्त न हों। ऐप के अनुसार refund कुंजी या rescue key और उस स्वैप का डेटा चाहिए, जिसमें लॉक किया गया आउटपुट और समय-सीमा शामिल हैं। Boltz Swap Restore अपने बैकअप से कुंजियाँ निकालता और जुड़े स्वैप खोजता है। खोज में xpub, विस्तारित सार्वजनिक कुंजी, इस्तेमाल होती है। इससे इतिहास सामने आ सकता है, लेकिन यह अकेली हस्ताक्षर या खर्च नहीं कर सकती। निजी कुंजी एक गुप्त मान है, जिससे ऐप तय शर्तों के अनुसार लेनदेन पर हस्ताक्षर करता है। ये कुंजियाँ डिवाइस पर रहती हैं। पैसा भेजने से पहले स्पष्ट हो कि बैकअप क्या लौटाएगा और कहाँ रखा है। [7] [3]
उपयोगकर्ता को क्रिप्टोग्राफ़िक शर्तें हाथ से नहीं निकालनी चाहिए, लेकिन ऐप को उन्हें जाँचना होगा। प्रोग्रामों के बीच डेटा भेजने वाले इंटरफ़ेस API से मिले पते पर केवल भरोसा करना पर्याप्त नहीं। ऐप नेटवर्क, राशियाँ और शुल्क, hash, कुंजियाँ और समय-सीमाएँ जाँचता है। खर्च के नियम यानी स्क्रिप्ट या Taproot में उन नियमों का पेड़ और उनसे बना पता भी मेल खाने चाहिए। Lightning इनवॉइस तय छाप और राशि के अनुरूप हो। सही व्यवस्था भी गलत जगह पैसे भेजने वाले प्रोग्राम को नहीं बचाती। [2]
Taproot में दोनों पक्ष MuSig2 से साझा हस्ताक्षर बना सकते हैं। यह key-path रास्ता सस्ता हो सकता है और स्वैप की शर्तें सार्वजनिक करना ज़रूरी नहीं बनाता। ऐप को script-path रास्ता भी चाहिए, जो साथी के सहयोग न करने पर शर्तों को सीधे इस्तेमाल करे: दिशा के अनुसार claim या refund के लिए। सामान्य स्वैप विफल हो तो दोनों पक्षों के हस्ताक्षर वाला refund पैसे जल्दी लौटा सकता है। लेकिन सेवा के सहयोग के बिना पैसे वापस लेने के लिए अन्ना को तय timelock के अनुमति देने तक इंतज़ार करना होगा। ब्लॉकचेन पर कम जानकारी दिखने से उस सेवा के सामने पहचान नहीं छिप जाती जिसने अदला-बदली कराई है। [3] [4]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Lightning Network, HTLC, Inbound Liquidity, Taproot, MuSig2, CLTV. इस प्रविष्टि का उल्लेख यहाँ भी है Lightning तरलता, Inbound Liquidity, Boltz, Lightning Service Provider.