Submarine Swap

通常のスワップでは利用者がオンチェーンのビットコインをロックし、サービスが利用者の Lightning 請求書を支払います。Reverse Submarine Swap では条件付きの Lightning 支払いを提供し、オンチェーン出力を取得します。別の通貨への両替や自分のチャネルの単純な閉鎖とは限りません。 [Boltz — Swap types and states]

SHA256 ハッシュに一致する preimage により、連動する支払いの決済とロック出力の取得が可能になります。逆方向ではクライアントが preimage を作り、公開前はサービスが Lightning HTLC を保留します。オンチェーン claim が秘密を公開する場合も、協調経路でオフチェーンに渡す場合もあります。保留は最終決済ではありません。 [Boltz — Swap types and states] [Lightning Loop — Architecture]

資金投入前に、ネットワーク、手数料込みの金額、ハッシュ、鍵、期限、スクリプトや Taproot ツリーと宛先アドレスの結び付きを検証する必要があります。請求書は合意したハッシュと金額に一致しなければなりません。API が返した任意のアドレスへ無検証で支払えば、正しい暗号技術も助けになりません。 [Boltz — Client verification]

Taproot スワップは双方の MuSig2 key-path 署名で容量を節約し、スクリプトを隠せます。相手が協力しない場合、クライアントは適切な script-path claim または refund に対応する必要があります。迅速な協調返金は追加の選択肢であり、単独回収の時間条件をなくすものではありません。 [Boltz — Claims and refunds] [Lightning Loop — Architecture]

通常のスワップが失敗しオンチェーン資金がロック済みなら、クライアントが refund 取引を作って配信します。単独経路は timelock を待ちます。未決済の逆方向 Lightning 支払いなら、HTLC の取消しで資金を解放でき、そのような利用者の返金取引は不要です。ただし preimage 公開後、決済済み支払いが自動で戻るとは考えないでください。 [Boltz — Swap types and states] [Boltz — Claims and refunds]

スワップにはサービス、経路、オンチェーンの費用がかかり、通常スワップの失敗には返金手数料も加わり得ます。claim の承認前に preimage を公開すると期限との競争が生じます。Loop は timeout 直前の sweep 手数料引上げが当初上限を超え得ると明記しています。見積額はすべてのリスクの無条件な上限ではありません。 [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]

クライアントに応じて refund 鍵または rescue key とスワップ情報を保存します。別ウォレットの通常のシードは万能な復元手段ではありません。Boltz restore は鍵を導出してスワップを検索しますが、xpub だけでは署名できません。サービス識別子だけでなく、スクリプト、出力、timeout も重要です。 [Boltz — Swap restore] [Boltz — Claims and refunds]

Boltz の逆方向で invoice.settled は preimage 開示後の Lightning 決済を意味し得ますが、Boltz はクライアントが claim を配信したか追跡しません。完了扱いや再支払いの前に、自分の宛先出力と必要な承認を確認します。Taproot key-path が減らすのはスクリプトの可視性であり、提供者の金額や時刻の知識ではありません。 [Boltz — Swap types and states] [Boltz — Client verification]