Dead Man’s Switch

一种恢复模型可以给所有者立即可用的分支，给其他密钥等待后才可用的分支。住院、设备丢失或疏于维护也可能满足同一条件。因此，技术上的访问能力不能证明当事人的生活状况，也不能确定合法继承人。设计前应明确系统实际观察的具体事件。 [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

deadmansswitch.net 会在未收到定期确认后发送预先写好的邮件。这与 Bitcoin Script 属于不同层次。设计自己的方案时，应分别评估账户可用性、收件人能否收到消息，以及信息提前泄露的可能。消息可以指出备份位置，却不能证明花费条件已经满足。修改计时器无法收回已发送的 seed；发生泄露后，还必须处理资金控制权。 [Dead Man’s Switch — Service mechanism]

BIP 65 与 OP_CHECKLOCKTIMEVERIFY 检查绝对区块高度或时间门槛。BIP 112 与 OP_CHECKSEQUENCEVERIFY 配合 BIP 68，可以强制要求某个 UTXO 达到指定年龄。按时间计算的相对锁使用 512 秒单位及 median-time-past，而不是手机时钟；BIP 113 描述前 11 个区块时间戳的中位数。以区块表示的期限不能当作精确的日历截止时间。 [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

如果一个在 H 确认的 UTXO 拥有等待 1000 个区块的恢复分支，那么在其他条件满足时，该分支最早可在 H+1000 使用。登录应用或向其他输出收款，都不会重置它的年龄。更新相对期限需要花费这个输出，并确认一个采用预期策略的新输出。应分别跟踪每个 UTXO；仅更新钱包的一部分，可能让旧资金仍接近门槛。 [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

在主分支始终可用的模型中，等待期结束不会取消主分支的权限，而是增加一个可用的恢复分支。仍须有人完成签名与交易广播。如果两个分支均有效，决定同一 UTXO 被如何花费的是已确认交易，而不是应用里的“所有者”或“继承人”标签。因此，设计还应考虑更新过晚以及相互竞争的花费。 [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

单独使用 nLockTime 只会推迟某笔交易；它不能证明有权限的密钥无法签署其他付款。预签名方案必须明确输入、输出、签名权限和手续费来源。若另一笔已确认交易花费了它的输入，原先的预签名便无法使用。因此，修改方案不能只改文档，还应检查实际 UTXO，以及收件人是否拿到了新的恢复材料。 [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

由这些机制可推导出：应在最近期限前留出余量，保持提醒有效，并备好手续费资金。更频繁地更新会产生交易费用；更长的等待期会延长恢复分支不可用的时间。恢复者需要正确密钥、descriptor 等策略说明，以及可用工具。如果备份被锁在无法联系的所有者账户或设备中，就形成循环依赖。 [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana 提供 Signet 测试指南。独立测试环境可以验证过早尝试、恢复分支到期，以及更新某个输出。还应加入提醒未送达、主密钥丢失、从保存材料恢复等自设场景。更换收件人后，要检查旧密钥与旧 UTXO 仍允许什么操作。应区分生成签名、mempool 接受与交易确认；一个场景成功不能证明整个方案没有缺陷。 [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]