Submarine Swap

安娜把比特币放在普通钱包里，商店却给她一张 Lightning 发票，也就是付款请求。普通 swap 让她按约定条件在链上锁定比特币，由服务商支付发票作为交换。若她想把 Lightning 余额转到链上地址，就需要反方向的 Reverse Submarine Swap，例如 Loop Out。她不必因此关闭自己的支付通道。但交换不会创造钱，Lightning 付款仍然需要可用的路径。 [1] [4]

想象一个秘密：可以验证它的数字指纹，却几乎不可能从指纹反推出秘密。这里的秘密值叫 preimage，数字指纹称为 hash，也就是哈希，由 SHA256 计算得出。称为 HTLC 的条件付款把指纹与期限结合。在反向 swap 中，安娜的客户端生成秘密。服务商先让她的 Lightning 付款保持待处理，再在链上锁定对应的比特币。安娜通过 claim 操作领取资金时，会在链上公开秘密，或在双方合作时将其交给服务商。服务商便能结清关联付款。待处理不等于已经支付。 [1] [4]

服务商的通知不等于目标钱包里已经收到资金。Boltz 文档说明，反向 swap 的 invoice.settled 状态可能在交出 preimage、结清 Lightning 发票后出现。服务商并不追踪安娜的客户端是否真正广播了 claim 交易。因此，她需要核验目标输出，也就是分配给自己钱包的那部分比特币，以及所需的区块确认。区块是一组加入区块链的交易。交易被纳入区块时获得首次确认，之后每接上一个新区块，就增加一次确认。状态不明确，并不是立刻重复付款的好理由。 [1] [2]

普通 swap 中，安娜的比特币可能已锁在链上，但发票尚未支付。此时退款 refund 需要由她的客户端构造并广播交易。若服务商不配合，就必须等待 timelock，即约定的时间条件。反方向尚未结清的 Lightning 付款则可能取消待处理 HTLC，使余额重新可用，不需要安娜发送链上 refund 交易。但这不代表公开 preimage 后，已经结清的付款会自动退回。必须分清方向和当前阶段。 [1] [3]

安娜应比较发送金额和实际到账金额。差额可能包括服务费、Lightning 路由费和链上交易费。失败的普通 swap 还可能增加退款交易费。时间同样重要：claim 公布时可能已泄露 preimage，却尚未获得区块确认。Loop 文档指出，接近 timeout 时，客户端可能把 sweep，也就是领取资金的交易，所支付的费用提高到原有限额之上。因此，密码学关联并不承诺交换即时、免费或毫无风险。 [5] [6]

另一个钱包的恢复词未必能恢复进行中的 swap。具体取决于客户端，可能需要 refund 私钥或 rescue key，以及该交换的资料，包括被锁定的输出和期限。Boltz Swap Restore 能从自身备份派生密钥，并查找相关交换。查找使用 xpub，即扩展公钥：它可能暴露历史记录，但本身不能签名或花钱。私钥是应用用于按相应条件签署交易的秘密值。这些密钥保留在设备上。在发送资金前，就应弄清备份能恢复什么、保存在哪里。 [7] [3]

用户不应被要求手算密码学条件，但客户端必须代为检查。不能仅仅相信 API，也就是程序交换数据的接口，所返回的地址。客户端要核验网络、金额与费用、hash、密钥和时间条件。还必须核验脚本，即支出规则，或 Taproot 中的规则树，以及据此派生的地址。Lightning 发票应与约定的指纹和金额一致。机制再正确，也救不了把钱发往别处的软件。 [2]

使用 Taproot 时，双方可以通过 MuSig2 生成共同签名。这条 key-path 路径可能费用更低，也不必公开 swap 条件。但客户端还需要 script-path 路径，在对方不合作时直接使用相应条件：根据方向执行 claim 或 refund。普通 swap 失败后，双方共同签署的 refund 可以更早退回资金。但如果安娜要在服务商不配合的情况下自行取回资金，就必须等到约定的 timelock 允许退款。链上公开的信息较少，也不意味着对组织交换的服务商匿名。 [3] [4]