保管比特币最坏的情形是钥匙被偷了而你浑然不觉——转账广播的那一刻，钱已经回不来了。2023 年 1 月 9 日，James O’Beirne 和 Greg Sanders 在邮件列表公布 OP_VAULT 提案，2 月 3 日立项为 BIP-345，正面瞄准这个最坏结果：给一笔钱装上「提款必须先公示、到期前你随时能反悔」的共识级金库。这份提案的 Proposed-Replacement 字段写着 443，最终状态 Closed，思路后来在 BIP-443 的契约讨论中延续。
机制的地基是 Taproot。用户把币锁进一个至少含两片脚本叶的默克尔树：一片含 OP_VAULT，管正常取款；另一片含 OP_VAULT_RECOVER，管紧急恢复。OP_VAULT 和 OP_VAULT_RECOVER 并非新字节，而是给 Tapscript 里本无条件成功的 OP_SUCCESS187（0xbb）与 OP_SUCCESS188（0xbc）加上约束——这是 Taproot 升级挂钩的惯用手法，也因此对旧节点向后兼容（只会收紧验证规则，不会出现旧规则合法新规则非法的区块）。
整个生命周期由四种交易串起来。金库交易把币装进上述 Taproot 结构。触发交易花掉 OP_VAULT 叶的输出，公开广播「我要提款到这几个地址」，它把当前这片叶子替换成预先约定的脚本模板，只允许在触发时填若干参数，其余叶子必须原封不动——恢复路径就这样被永久保留；交易还可以顺手把一部分余额原样锁回同一 scriptPubKey 做部分续存（revault）。提款交易在延时窗口走完之后，花掉触发输出，把币付给触发时就锁定的那组输出，落点由 OP_CHECKTEMPLATEVERIFY 的承诺哈希钉死。恢复交易则走 OP_VAULT_RECOVER 叶，在提款交易确认之前的任何时刻，把钱送到预设的恢复路径。换言之：日常花费要先排队，盗窃者想快也得排队；而在队伍里，真主人随时可以把钱整个拉回安全屋。
相对 2022 年公开的 simple-ctv-vault 那类纯脚本方案，提案逐条列出要补的短板：预签名交易把金额、目的地、手续费全部焊死，资金必须流经固定中转输出；费用高峰来了连批量操作都做不了。BIP-345 的设计目标因此是：同一份金库配置可反复接收多笔存款；恢复与提款都能批量；支持不限次数的部分提取而无需重新开金库；提款目的地在触发时才决定，不再需要专职中转钱包；手续费也在触发时才定。安全上特别注明要避免引入内存池钉住（pinning）向量；早期版本硬依赖 v3 交易与临时锚点策略，修订后改为「受益于但不依赖」。
一个典型个人配置能帮你建立直觉：日常用硬件钱包单签触发，延时设一天；恢复钥匙用夸张一点的方式保管——纸抄分片、不同厂牌设备拼的 2-of-3，甚至社会分布的钥匙。手机跑一个监听器盯金库输出，一旦看到自己没发起的触发交易，立刻发起恢复。恢复钥匙可以慢得离谱，因为它只在最坏的一天登场；日常体验却几乎不变，只是每笔提款多等一天。
常见误区有四个。其一，把金库当成防盗保证：它防的是「延时窗口内的既成转账」，窗口长短与监听是否在线决定实际保护力。其二，以为恢复要凑齐日常钥匙：走的是另一片叶子，规则由建库时写定，还可以叠加可选的恢复授权脚本。其三，把它与通用契约混同：OP_VAULT 是特化契约（specialized covenant），故意不做任意状态机，换脚本短小与开销低。其四，以为它已可用：提案已关闭，主网没有这两个操作码的共识规则。
快速问答。问：延时用区块时间还是高度？答：时间锁规则由触发交易与模板参数决定，提案示例按高度天数配置。问：为什么强依赖 CTV？答：触发时必须把「终点长什么样」承诺进共识，CTV 是最简单安全的方式；原文注明换成其他锁定输出的原语也无须改动 OP_VAULT 部分。问：交易所会用吗？答：机构托管被明确列为目标用户。
风险提示：本文是协议提案科普，不构成投资建议，也不构成对任何钱包或托管方案安全性的承诺；延时金库依赖监听与响应纪律，配置失误同样可能锁死资金。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。