协议演进 / BIP/比特币改进提案 / BIP-128
BIP-128
用 JSON 统一保存由警报交易与带相对时间锁的恢复交易组成的预签恢复计划，让不同钱包生成、不同服务监控与执行。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-128 |
|---|---|
| 标题 | Timelock-Recovery Storage Format |
| 作者 | Oren Z <[email protected]> |
| 指定日期 | 2026-02-05 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Draft（草案） |
| 阅读版 | https://bips.dev/128 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0128.mediawiki |
二、放在哪一族
钱包恢复、继承与预签交易族。它建立的时间锁构件都来自更早的文档：
BIP-65：OP_CHECKLOCKTIMEVERIFY，原文以“一笔 nLocktime 设为未来日期的预签交易”作为传统做法的例子
BIP-68：共识强制序列号的相对锁定时间，本 BIP 计算取消期 nSequence 时直接遵循它
BIP-112：CHECKSEQUENCEVERIFY，脚本型钱包做相对锁时用
BIP-119 与 BIP-443：原文在比较脚本型方案时提到，称这类新操作码设想仍在讨论阶段
它与脚本型恢复钱包是两条路线之争：本 BIP 不要求用户先搬家到脚本钱包，而是让今天普通的 P2WPKH 钱包也能预签出带取消期的恢复计划；它标准化的只是这份计划的存储与交换格式（JSON），不是新的脚本或共识规则。
三、它要解决什么
3.1 单笔预签恢复交易的取消难题
预签交易是做恢复计划的一种办法，用于种子丢失或继承场景。最常见的例子是预签一笔交易，把 nLocktime 设在未来日期（见 BIP-65）。
它的局限在“顺利情形”下暴露：种子没丢、一切正常，但 nLocktime 快到了——用户必须动用钱包、花掉其中一个 UTXO，才能让那笔预签交易作废，防止它到期后直接把资金转走、中间没有取消期。对于把种子分存在多处地理位置的用户，这种被迫操作很恼人。
3.2 时间锁恢复计划：两笔交易加一段取消期
本 BIP 所称的 Timelock-Recovery plan，是预签一对交易，最终把资金转到一个或多个次级钱包；第二笔交易带特殊的 nSequence 相对时间锁，使主人始终有一段取消期。执行与监控这种计划，比广播并盯住一笔交易复杂：还要能加速第一笔交易、判断相对时间锁是否已过、更细致地处理链重组。
前提有了，缺的是格式：生成计划的钱包与监控/执行的服务若各用各的格式，计划就无法导出、导入与托付。本 BIP 要定的就是这份计划的统一存储格式。
3.3 为什么不用脚本型钱包替代
原文专门比较了脚本型路线：脚本可以用 OP_CHECKLOCKTIMEVERIFY（BIP-65）与 OP_CHECKSEQUENCEVERIFY（BIP-112）限制次级密钥只能在绝对日期后、或资金到账一段相对时间后使用，且新收到的资金自动纳入恢复机制，这些都是优点。
但缺点同样被列明：脚本钱包对硬件钱包更难正确实现、备份更容易漏（连基本多签都有人忘备份描述符）；脚本目前只能限制次级密钥“何时”能用，不能限制“如何”用——时间一到，次级密钥就能把钱转到任何地方，哪怕一切正常，主人也必须定期把 UTXO 花到新地址来“续期”，对超冷存储很不方便；新操作码方案（BIP-119、BIP-443）还在讨论中；而且新人通常从 P2WPKH 钱包起步，预签交易不必搬家，改用脚本功能却要新建钱包并转移资金，对大额持仓者门槛很高。
四、规则本身
4.1 计划由两笔交易组成
警报交易（Alert Transaction）：大体是一笔归集交易——绝大部分资金仍留在原钱包，但落到一个全新的、从未用过的地址，原文称之为警报地址（alert-address）；另有一笔手续费，以及一小笔固定金额发往若干锚地址（anchor-addresses），这些地址可用于通过 CPFP 加速警报交易。之所以叫“警报”，是因为监控区块链、发现这笔交易，就应当提醒主人：恢复计划已被启动——无论是有意、无意还是恶意。
恢复交易（Recovery Transaction）：把警报交易在警报地址上形成的那笔 UTXO，转到次级钱包的一个或多个地址（各地址金额可不同）。它带按用户所需取消期设置的特殊 nSequence 相对时间锁，遵循 BIP-68 的规则。
配套要求：警报交易必须不可延展（non-malleable），原文举例可借助 BIP-140；若警报交易可被延展，恶意矿工可换一笔 txid 不同的相似交易上链，恢复交易指向的 UTXO 便不存在、整份计划失效。两笔交易的 nLocktime 都不得高于当前区块高度。锚地址可以是 BIP-433 的 P2A 地址，也可以是参与者控制的其他地址（例如次级钱包的地址）；原文称写作时 P2A 尚未广泛采用、不太技术型的用户用它做 CPFP 加速有困难，因此目前推荐用普通地址。
有了可靠的监控工具盯住警报交易或警报地址，用户可以放心地把计划 JSON 在线备份；即使没有工具，定期手工查链也可以。若预签交易泄漏、警报交易被意外广播，用户有取消期（预计至少数天）把大部分资金转到新地址，从而使恢复交易失效。
4.2 取消期与 nSequence 的换算
用户以整天为单位指定取消期，范围 2–388 天。少于 2 天、或不足整天的部分不支持（原文称没有用处）；超过 388 天会溢出 nSequence 中相对时间锁的比特位，同样不支持。
换算遵循 BIP-68：置位 (1 « 22) 表示以 512 秒为单位计时，公式为：
n_sequence = (1 << 22) | round(cancellation_period_days * 24 * 60 * 60 / 512)
原文提醒：由于矿工能影响区块时间戳，取消期并不保证精确。
4.3 JSON 格式：必填与可选字段
计划保存为一个 JSON 对象。主要字段（标注必填者不得缺）：
kind（必填）：必须为 “timelock-recovery-plan”；id（必填）：不超过 100 字符的非空唯一标识（如 UUID）；name（可选，最长 200 字符）、description（可选，最长 10,000 字符）；created_at（必填）：带时区偏移的 ISO 8601 时间戳。- 生成方信息：
wallet_version、wallet_name、wallet_kind均为必填（各最长 100 字符）；plugin_version可选。 - 时间锁参数：
timelock_days（必填）：取消期整天数，2 到 388；anchor_amount_sats（必填）：警报交易发往每个锚地址的聪数，原文推荐 600 sats（高于粉尘限额）；anchor_addresses（必填）：最多 10,000 个地址；alert_address（必填）：接收绝大部分资金的警报地址。 - 警报交易数据：
alert_inputs（必填）：输入列表，每项为 “txid:vout” 格式，最多 2,439 项（按 400,000 wu 标准交易、每输入至少 41 字节算出）；alert_tx（必填）：原始交易的大写十六进制，最长 800,000 字符；alert_txid、alert_fee、alert_weight（必填，权重为正且不高于 400,000）。 - 恢复交易数据：
recovery_tx、recovery_txid、recovery_fee、recovery_weight均为必填，约束与警报交易对应项相同；recovery_outputs（必填）：最多 10,000 项，每项为 [address, amount_sats, label?] 数组，金额为正整数，label 可选、最长 200 字符。 metadata（可选，最长 10,000 字符，例如放数字签名）；checksum（必填）：8 到 64 字符的完整性校验和。
原文解释了为何 JSON 里除了原始交易，还冗余保存可从交易中解析出的信息：让前端界面在上传到任何服务之前就能展示计划，不必在前端做复杂解析；后端服务则应核对这些信息与原始交易是否一致，钱包实现若有偏差，服务还可依据 wallet_kind、wallet_version、plugin_version 写定制处理。原始交易要求大写十六进制，是为了便于在前端以二维码展示（大写字母数字模式的二维码更紧凑）。服务器可以另加限制，例如拒绝保存过大的交易。
4.4 校验和算法
除顶层对象外，所有内部值都是基本类型或数组，这是刻意的，好让取值转成 JSON 字符串时结果确定。算法是：把顶层对象（不含 checksum 本身，可选字段无值时不纳入）转成 [key, value] 键值对数组，排序后按 ECMAScript 的 JSON.stringify 规范字符串化，对结果取 SHA-256 哈希（小写十六进制），取至少前 8 个字符作为校验和；钱包可选用更长的校验和。
4.5 监控与验证的注意事项
验证警报交易是否有效很简单：用 Bitcoin Core 0.17+ 的 testmempoolaccept RPC 即可。验证恢复交易则复杂，因为它依赖警报交易新造的 UTXO；直接把两笔一起交给 testmempoolaccept 会因相对时间锁未到期、UTXO 未确认而失败。原文建议想验证整份计划的服务自行解析恢复交易、手工核对签名，并拒绝复杂的花费脚本——若等到执行时才发现恢复交易无效，资金可能被永久锁死。
参考实现是 Electrum 钱包的 Timelock Recovery 插件，原文给出了其仓库路径与示例 JSON。
五、谁必须动
普通持币人：若用此法做恢复或继承计划，需要理解两段式结构：警报交易一旦上链就意味着计划已启动，自己只有取消期这段时间把资金转走叫停；平时则须保管好计划 JSON 并确保有人（或服务）在监控警报地址。
钱包开发者：生成计划的一方要按 4.1–4.4 构造两笔预签交易、换算 nSequence、导出合规 JSON；导入的一方要校验校验和与字段约束。
监控/执行服务：负责盯链发现警报交易、判断相对锁是否到期、必要时用锚地址 CPFP 加速，并按 4.5 的方式提前验证恢复交易，不要等到执行时才发现无效。
全节点与矿工：不必为本 BIP 改动。两笔交易都是普通交易；节点的 testmempoolaccept 只是被借用的验证工具。
共识层：无改动。相对时间锁的共识语义来自 BIP-68 等既有文档。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案）。按仓库状态解释：它仍是一份草案规范，没有定稿，更没有证据表明各钱包与服务已经普遍按它互操作。原文给出的参考落点是 Electrum 的一个插件，除此之外本页不臆测采用情况。它的价值目前在于把“警报加恢复”的计划结构与字段清单写成了可讨论、可实现的文本。
常见误读：“把计划 JSON 备份到线上，预签交易泄漏了也没关系，反正有取消期。”
不完全对。原文的说法有条件：要有可靠工具监控警报交易或警报地址（或本人定期手工查链），取消期才有意义——没人发现警报交易上链，几天取消期一过，恢复交易就能把钱转走。取消期买的是“被及时发现后叫停”的时间，不是泄漏本身无害的保证。
七、延伸
- 阅读版：https://bips.dev/128
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0128.mediawiki
- 相关：BIP-65 OP_CHECKLOCKTIMEVERIFY、BIP-68 相对锁定时间、BIP-112 CHECKSEQUENCEVERIFY
- 仓库总目录：https://github.com/bitcoin/bips