Submarine Swapは、オンチェーンで持っているビットコインを使ってLightning Network経由で支払う仕組みです。ブロックチェーンはビットコインの公開取引履歴で、Lightningは個々の支払いをその履歴に別々に記録せず、素早く送金できる仕組みです。逆方向はReverse Submarine Swapと呼びます。別の通貨を買うのではなく、手数料を差し引いた資金をこの二つの支払い方法の間で移します。暗号学的な条件と時間の条件が両方の支払いを結びます。アプリは条件を検証し、交換を間に合うように完了させるか、資金を取り戻す手続きを行う必要があります。
アンナは普通のウォレットにビットコインを持っています。ところが店から渡されたのは Lightning インボイス、支払いの請求です。通常のスワップでは、合意した条件でビットコインをオンチェーンにロックし、代わりにサービスが請求を支払います。Lightning 残高をオンチェーンのアドレスへ移す場合は、Loop Out などの Reverse Submarine Swap を使います。自分の支払いチャネルを閉じる必要はありません。ただし、お金が新たに生まれるわけではなく、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.