救援交易（Rescue Transaction）

一句话定义： 预先签名的后备交易：密钥泄露或闪电通道失败时保住资金。

救援交易（Rescue Transaction）是预先签好、以备紧急恢复之用的比特币交易。签名发生在风平浪静的设置阶段；广播只在实际出事时进行。

常见模式：

• 金库恢复交易。 金库（vault）设置里（热密钥 + 冷密钥 + 时间锁保护的提款路径），用户在设置时就预先签好「冷密钥回撤」交易。如果热密钥泄露、攻击者尝试花费，救援交易（已签名，只差广播）会在攻击者的回撤窗口到期前把资金扫到安全地址。
• 闪电通道承诺。 每一笔闪电通道承诺交易实质上就是预签的救援交易。如果通道对端消失，你广播自己最新的承诺交易，在链上取回资金（带 CSV 锁的等待窗口）。
• 多签应急恢复。 2-of-3 多签加上一个为「三位共同签名方一致同意的最坏情况」预先签好的交易：共同签名方 A 失联时，B 和 C 手里有一笔预签交易，可把资金转移到排除 A 的新设置。
• 继承计划。 预签交易中包含继承人恢复路径：时间锁到期后可以广播一笔交易认领资金。

救援交易的威力所在：

• 最糟糕的时刻无需签名。 出事时，用户（或继承人）可能慌乱、被胁迫或根本不在场。预签交易不需要你在危机中保持清醒决策。
• 共同签名方可能离线。 预签的多签恢复不需要临时联系那些可能够不到的共同签名方。
• 时间锁强制。 一些救援交易使用 CSV/CLTV，只在指定延迟后才生效，给主用户在误触发时叫停的机会。

存储与安全：

• 救援交易存在哪里很重要。 签名后的交易对该目的地而言与私钥同等敏感。任何人拿到它都可以广播。
• 手续费考量。 预签交易的手续费在签名时就固定了。如果广播前费率飙升，交易可能因费太低无法确认。有的设计会按不同费率预签多个版本。
• 状态漂移。 多输入交易引用的 UTXO 可能已被花费。定期重签才能保持救援有效。
• 操作纪律。 设置时就要测试救援交易。关键时刻才发现预签交易无效，比没有救援计划更糟。

生产环境的真实案例：

• Liana（Wizardsardine 的钱包）：主打场景正是这个模式——恢复密钥在可配置的时间锁之后可花费。
• Casa、Unchained、Nunchuk 多签服务：通常在客户设置中维护预签恢复交易。
• DIY 金库实现：Sparrow + 硬件签名器 + Liana 式脚本可以手工构造任何这类设计。

救援交易是比特币自我托管里最被低估的工具之一。它把理论上「万一 X 怎么办」的场景变成「X 发生时我们广播这个文件」的现实。前期投入是真实的；但需要它的那天，回报巨大。

相关词条： 分层多签（Hierarchical Multisig） · 闪电通道（Lightning Channel） · PSBT（部分签名比特币交易） · 时间锁合约（Time-Locked Contract）