Submarine Swap v běžném směru mění on-chain bitcoin za Lightning platbu; Reverse Submarine Swap jde opačně. Hash a časové podmínky propojují obě větve tak, aby správně ověřující klient nemusel svěřit službě neomezenou úschovu jistiny.
U běžného swapu uživatel uzamkne on-chain bitcoin a služba platí jeho Lightning fakturu. U Reverse Submarine Swap uživatel poskytne podmíněnou Lightning platbu a vyzvedává on-chain výstup. Není to automaticky výměna za jinou měnu ani prosté uzavření vlastního kanálu. [Boltz — Swap types and states]
Preimage odpovídající SHA256 hashi umožní dokončit navázanou platbu i vyzvednout uzamčený výstup. U reverse postupu klient vytváří preimage a služba před jeho odhalením drží Lightning HTLC jako čekající. On-chain claim může tajemství odhalit; kooperativní cesta je může předat službě mimo řetězec. Čekající platba ještě není konečné vypořádání. [Boltz — Swap types and states] [Lightning Loop — Architecture]
Před financováním musí klient ověřit síť, částky včetně poplatků, hash, klíče, časový limit a vazbu skriptu nebo Taproot stromu na cílovou adresu. Faktura musí odpovídat dohodnutému hashi a částce. Správná kryptografie nepomůže, když aplikace bez kontroly zaplatí libovolnou adresu z API. [Boltz — Client verification]
Taproot swapy mohou použít MuSig2 key-path podpis obou stran, který šetří místo a skrývá skript. Když druhá strana nespolupracuje, musí klient podporovat příslušný script-path claim či refund. Rychlé kooperativní vrácení je další možnost, nikoli zrušení časové podmínky jednostranné obnovy. [Boltz — Claims and refunds] [Lightning Loop — Architecture]
U nezdařeného běžného swapu s již uzamčenými on-chain prostředky klient aktivně připravuje a vysílá refund transakci; jednostranná cesta čeká na timelock. U nevyřízené reverse Lightning platby se HTLC může zrušit a prostředky odblokovat bez takové refund transakce uživatele. Po odhalení preimage však nelze spoléhat, že se již vypořádaná platba sama vrátí. [Boltz — Swap types and states] [Boltz — Claims and refunds]
Swap má servisní, směrovací a on-chain náklady; neúspěšný běžný swap může přidat další refund poplatek. Odhalení preimage před potvrzením claimu vytváří závod s časovým limitem. Loop výslovně popisuje, že při blížícím se timeoutu může zvýšení sweep poplatku překročit původní limit. Odhad ceny tedy není bezpodmínečný strop všech rizik. [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]
Refund klíč nebo rescue key a údaje konkrétního swapu uchovávejte podle použitého klienta; běžný seed jiné peněženky není univerzální obnova swapu. Boltz restore používá odvození klíčů a vyhledání swapů, ale xpub sám nepodepisuje. Důležité jsou také skript, výstup a timeout, ne pouze identifikátor služby. [Boltz — Swap restore] [Boltz — Claims and refunds]
V Boltz reverse postupu může invoice.settled znamenat vypořádání Lightning faktury po předání preimage, zatímco Boltz nesleduje, zda klient vyslal claim. Ověřte vlastní cílový výstup a potřebná potvrzení, než výsledek označíte za dokončený nebo zopakujete platbu. Taproot key-path omezuje viditelnost skriptu, nikoli znalost částky a načasování u poskytovatele. [Boltz — Swap types and states] [Boltz — Client verification]
Pro nejúplnější obraz čtěte toto heslo společně s Lightning Network, HTLC, Inbound Liquidity, Taproot, MuSig2, CHECKLOCKTIMEVERIFY. Opačným směrem na něj odkazují také Lightningová likvidita, Inbound Liquidity, Boltz.