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]