Bitcoin Vault

在普通单签钱包中，拿到密钥的窃贼可以直接创建付款。Vault 旨在限制这种即时流失：操作密钥启动流程，但不应单独绕过等待期和恢复路径。因此应问清哪些密钥组合能够直接付款，哪些必须经过中间状态。仅有 vault 标签或应用里的延迟转账，不能证明区块链强制执行这些限制。 [BIP 345 — OP_VAULT]

模型区分已存入的 UTXO、已确认的 unvault 中间输出和最终完成的付款。如果在区块 H 确认的中间输出，其普通提取分支要求等待 144 个区块，那么在其他条件满足时最早可于 H+144 使用。恢复分支应允许更早干预。这不是精确的 24 小时，也不是自动撤销付款：有效干预必须赶在最终支出确认之前。 [BIP 345 — OP_VAULT] [BIP 112 — CHECKSEQUENCEVERIFY]

有些结构使用现有规则和预签名交易。它们通过要求安全删除一次性签名密钥，或要求其他独立参与者批准替代交易，限制其他支出路径。网络本身并不证明密钥已删除。保留的秘密副本可能绕过预定路径。预签名交易也是恢复材料的一部分：仅有 seed，可能无法重新生成已删除密钥做出的签名。 [BIP 345 — OP_VAULT] [Revault — Transaction specification]

Revault 规范区分 stakeholders、managers 和 cosigning servers。其 deposit 输出使用 N-of-N stakeholder 密钥；unvault 输出允许 stakeholder 路径，或在 X 个区块后使用 managers 与 cosigners 路径。Cancel 把 unvault 输出送回 deposit 策略，emergency 则转入 Emergency Deep Vault。另有由 stakeholders 签署的 bypass。因此，若所有 stakeholder 密钥都泄露，该模型并不保证延迟；它也不是所有 vault 的通用描述。 [Revault — Transaction specification]

在 2026 年 9 月 8 日的审阅中，BIP 345 状态为 Closed，Proposed-Replacement 指向 BIP 443。它原本将 OP_VAULT、OP_VAULT_RECOVER 与 OP_CHECKTEMPLATEVERIFY 结合。BIP 443 提出更通用的 OP_CHECKCONTRACTVERIFY，即 OP_CCV，状态为 Draft，激活机制尚未确定。BIP 119 也为 Draft。BIP 编号、测试实现或已发布的 vault 示例，都不能单独证明这些规则已在 Bitcoin mainnet 激活。 [BIP 345 — OP_VAULT] [BIP 443 — OP_CHECKCONTRACTVERIFY] [BIP 119 — CHECKTEMPLATEVERIFY]

监控程序需要识别非预期提取，而不只是看到一笔交易。响应需要有效的救援交易、可达的网络和足够的费用。提交到 mempool 不等于确认；拥堵、pinning 或不合适的提费策略可能耗尽窗口。Revault 规定了 CPFP，并在部分救援交易中使用 ALL | ANYONECANPAY，以便添加支付费用的输入。规范中的历史费率不是今天的费用建议。 [BIP 345 — OP_VAULT] [Revault — Transaction specification]

转入恢复脚本，只有在合法所有者以后能满足其条件时才有帮助。无法取得的密钥、缺失配置或丢失预签名，可能让防盗变成永久锁死自己的资金。过于容易触发的救援分支，也可能让他人反复取消提取进行骚扰。因此要区分启动保护转移的权限与从目的地花费的权限，并核验这两个角色。 [BIP 345 — OP_VAULT] [Revault — Transaction specification]

核验应列出所有提取和 bypass 路径、共识假设、必需备份及响应时间。独立测试环境应覆盖正常提取、过早尝试、意外 unvault、监控故障和费用资金不可用。结果必须区分有效签名、mempool 接受和确认。成功演示一个场景不能证明所有分支安全；这些模型不是将真实资金存入实验脚本的指示。 [BIP 345 — OP_VAULT] [Revault — Transaction specification]