Bitcoin Vault

安娜把部分积蓄存成比特币。钱包是接收和发送比特币的应用程序或设备。这里的签名，是用私钥这个秘密数值，生成可以验证的付款授权证明。其他人无须知道这个秘密，就能检查签名。普通钱包若只由一个密钥控制，窃贼拿到密钥，就能直接签署付款，把钱转到自己的地址。Bitcoin Vault 希望改变这个过程：日常提款密钥只能启动流程，给安娜留下挽救资金的机会。可以把它想成带等待期和紧急转移通道的保险柜。但这个比喻成立的前提，是网络中的花费条件确实强制执行这些限制。应用里的倒计时并不够。Hardware Wallet 是保护签名密钥的硬件设备，也不自动等于 vault；它解决的是安全问题的另一个环节。 [1] [6]

交易输出记录一笔金额，以及之后花费这笔金额必须满足的条件。Bitcoin 记录可供花费的交易输出，称为 UTXO。区块把交易组成一批，加入共同历史记录。在简单模型中，初始交易花费原来的输出，并创建一个带等待条件的新输出。这一步叫 unvault。最终付款要稍后才能进行，而恢复分支允许提前介入。假设中间输出在区块 H 确认，等待要求为 144 个区块，那么普通路径最早可在 H+144 使用，并且仍须满足其他条件。这不等于准确的 24 小时，因为区块不会按固定时刻产生。它也不是撤销已经完成的付款：恢复交易必须抢在最终花费之前确认。 [1] [5] [7]

安娜发现了一笔并非自己发起的提款。接下来，她需要正常运行的网络监控、有效的恢复交易，以及支付手续费的能力。Mempool 保存尚未确认的交易；被它接收还不够。网络拥堵或 pinning，也就是攻击者妨碍交易被替换或确认的做法，都可能拖延应对。Revault 方案考虑了 CPFP：用后续交易增加手续费，吸引矿工把两笔交易一起确认。某些恢复交易采用 ALL | ANYONECANPAY 签名模式，允许加入额外输入来支付手续费，这些输入指向其他尚未花费的金额。这些只是特定方案中的工具，并不保证及时确认。规范中的历史费率也不是今天的建议费率。 [1] [4]

保护性转移可能拦住窃贼，却给安娜留下另一个问题：目标钱包以后必须真的能用。仅仅知道地址还不够。她需要所要求的密钥、花费条件说明，以及可能预先准备好的交易。触发保护性转移的权限，也不同于从目标地址花钱的权限。监控者可以只有前一种，而没有后一种。但如果恢复路径太容易触发，别人也可能反复阻止正常提款。因此，好的方案不仅要防盗，还要考虑恢复访问，以及保护机制本身被滥用的问题。 [1] [4]

一些 vault 使用现行规则和预签名交易。所需签名在设置阶段生成；之后，安全性可能依赖一次性密钥被彻底删除，或者依赖独立的共同签名者拒绝其他路径。网络无法核实一个人是否真的删除了密钥的所有副本。隐藏的副本可能绕过预期保护。备份也可能不仅是一份 Seed Phrase，即用来派生钱包密钥的助记词。这些词未必能重新生成已删除的一次性密钥所留下的缺失签名。因此，预签名交易及其相关数据可能是恢复资金不可缺少的材料。 [1] [4]

Revault 表明，问清谁持有密钥只是第一步。Stakeholders 掌握主要权限；managers 管理日常提款，cosigning servers 参与共同签名。存款要求 N-of-N，也就是全部指定 stakeholders 的签名，这属于 Multisig：通过多个密钥共同批准。中间输出可以走 stakeholders 路径花费，或者等待 X 个区块后，由 managers 和服务器共同花费。Cancel 把它送回原来的存款条件；紧急转移则送入 Emergency Deep Vault。Stakeholders 还有直接的 bypass 路径。拿到他们全部密钥的人无需等待。这是某份具体规范的设计，并非所有 vault 的通用规则。 [4]

BIP 是描述 Bitcoin 提案或标准的文档，有编号不代表已激活。本次核验日期为 2026年10月17日：BIP 345 状态为 Closed，Proposed-Replacement 字段指向 BIP 443。原提案把 OP_VAULT、OP_VAULT_RECOVER 与 OP_CHECKTEMPLATEVERIFY 结合，用这些指令限制提款路径。BIP 443 提出更通用的 OP_CHECKCONTRACTVERIFY，简称 OP_CCV，目前仍为 Draft，激活机制尚未确定。涉及 OP_CHECKTEMPLATEVERIFY 的 BIP 119 也为 Draft。它们属于 Covenants 的讨论，即限制一个输出后续用途的规则。公开代码或演示并不能证明 mainnet，也就是 Bitcoin 主网，已经强制执行这种保护。 [1] [2] [3]

在把积蓄交给 vault 之前，安娜需要理解正常提款、恢复流程和每条 bypass 路径。实际演练应在独立测试环境里完成：正常提款、等待期未结束时的尝试、意外的 unvault、监控中断，以及没有手续费资金的情况。有效签名、被 mempool 接收和区块确认，是不同阶段。一次成功演示不能证明其他分支也经过检验。对新手来说，重点是 vault 增加了反应时间，也增加了必须由某人可靠履行的职责。本文不是把真实资金转入实验性脚本的操作指南。 [1] [4]