自托管最常见的剧本不是被黑客，而是密钥先于主人出问题：助记词散落三地要凑齐才能花、设备报废、或者最坏的健康意外。预签名交易是老牌对策——提前把币签好、锁一个未来时间，塞给家人或托管服务，到期自动可花。它的软肋同样明显：如果一切正常，用户必须赶在时间锁到期前主动花掉那笔 UTXO 来销毁旧剧本，对把密钥分成多地的家庭来说，这是一年一度让人提心吊胆的闹钟。BIP-128 想在“留后路”和“不用年年救火”之间找一个标准答案，2026 年 2 月起草，作者是 Oren Z，状态 Draft。
它的核心构件是“时间锁恢复计划”：一对交易，而不是一笔。第一笔把资金挪到一个中间结构；第二笔再把中间结构的钱转给一组备用钱包，但给它加的不是绝对时间、而是相对锁定——必须等第一笔上链后再过一段观察期才生效。这个顺序反转是关键：只要用户活着且正常用钱包，恢复路径上的币早就被日常交易花走，整条剧本自然作废；就算用户忘记维护，备用路径也有一段可以抢救的窗口，而不是时间一到直接放行。相对锁定走的是既有 consensus 语义，和高度锁与时间锁两套口径都兼容。
而 BIP-128 真正的主题其实是“文件格式”：这对交易、它们的签名进度、哪笔 UTXO 被钉住、观察期多长、由谁负责广播与加速，全部塞进一个标准化容器。为什么格式值得单独立一份 BIP？因为执行一份恢复计划远不止“广播第一笔”：服务要持续监听相对锁定是否已过、要在重组时判断该退到哪一步、要在用户还能操作时配合加速第一笔交易。过去每家钱包用各家私有结构，托管方想同时服务多家钱包就得写一堆适配器；有了导入导出格式，一家服务能吃所有钱包导出的剧本。
把时间线摆出来最直观。平静期：主密钥正常，一切如常，恢复计划静静躺在两家托管方手里。触发日：用户出事，托管方或家人用容器里的第一笔交易让资金进入中间结构。观察期：相对锁定倒数，期间任何掌握主密钥的人都能花掉资金自动撤销；没人动，则第二笔解锁，币落到备用钱包。设计上的诚实之处是：它没有承诺免信任，撤销权仍属于主密钥，托管方也仍是“执行方”而不是“判断方”，这两点它都写在动机与限制里。
常见误区。一，把它与 BIP-65 一笔带过地画等号：BIP-65 定义的是绝对时间锁字段这一层积木，BIP-128 在其上组织两段式计划，还额外规定文件格式与撤销窗口。二，以为有了它就不需要备份主密钥——恰恰相反，主密钥是撤销机制的根基，剧本只是保险丝。三，以为托管服务能自动判断主人失能——它不能，它只会照剧本执行，这是特性不是缺陷，剧本本身已经是全部判断。
快速问答。问：观察期一般设多久？答：由计划自定，没有标准值；太长增加被抢先广播的暴露面，太短压缩抢救时间，需要家庭自己权衡。问：它需要软分叉吗？答：按提案文本不需要，积木是既有时间锁语义。问：与多签继承方案什么关系？答：多签靠“多人合意”防单人风险，它靠“时间加默认路径”防单人失联，可以叠加使用。
一条算术线帮你校准直觉：假设观察期是三十六个月、用户平均每两年动一次这部分余额，那么恢复路径在任一时刻的“可撤销概率”取决于最近一次动钱包的时间离观察期终点还有多远——把这笔时间账摊开，就是这份 BIP 全部设计权衡的焦点。
风险提示：预签名与继承安排涉及真实资产处置，签署前务必在测试网完整演练一遍；本文不构成法律或投资建议，涉及继承的安排请咨询专业人士，并以官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。