OP_CHECKTEMPLATEVERIFY

安娜想预留一笔资金，以后分给彼得和伊娃。她不希望仅仅依靠替她保管资金的人的承诺。在 Bitcoin 中，尚未花费的资金记录为交易输出，称为 UTXO；每个输出都包含金额和使用条件。CTV 可以把具体的分配计划加入这些条件。有人花费该输出时，节点，也就是检查网络规则的软件，会验证新交易是否遵守计划。不同的收款人或偏离预定的金额都不能通过检查。Jeremy Rubin 在 BIP119 中描述了这一提案，其 BIP 编号于 2020 年分配。 [1] [3]

模板规定转账的结构：输入引用多少个先前的输出，以及必须创建哪些新输出。对于新输出，它固定金额和脚本，也就是日后的花费条件。进一步说，BIP119 还包括交易版本、用于整笔交易时间约束的 nLockTime、可能影响时间锁的输入字段 nSequence，以及当前受检查输入的序号。如果任何 scriptSig，也就是提供花费数据的输入脚本，不为空，还会加入覆盖全部 scriptSig 字段的哈希。因此，这不只是一份收款人名单：更改其他被覆盖的字段，也会得到不同模板。对具体旧币的引用和它们的金额则是另一件事，下面会解释。 [1]

字节是衡量数据大小的常用单位。提议中的检查使用通过 SHA256 算出的 32 字节模板哈希。节点从正在花费该输出的交易中计算同样的指纹，不匹配就拒绝。数字签名利用私钥这个秘密数值证明付款获得授权，同时不泄露私钥。脚本的其他部分可以要求签名，CTV 并不是在所有场景中取代签名。其他长度的参数不会执行这项检查，而是留给未来扩展；中继策略仍可能拒绝它们。因此，参数写错并不意味着资金会被安全地锁住。 [1] [4] [12]

下面的例子使用 sats，即比特币的最小单位。模板哈希不直接包含 outpoint，也就是被花费的具体 UTXO 引用，也不直接包含其输入金额。但输入数量仍然固定。假设只允许一个输入，输出合计 99,000 sats。价值 100,000 sats 的输入会留下 1,000 sats 手续费。如果输入低于输出总额，就无法支付这笔交易；如果更高而输出不变，多出的价值会成为手续费，不会自动生成找零。 [6] [9]

模板可以规定资金必须先转到另一个输出，而后者的脚本包含延迟和恢复路径。这样就能为不希望发生的提款留出反应时间。不过，CTV 不是完整的安全系统：密钥、后续输出条件、监控以及恢复交易能否及时确认，都很重要。部分限制也可以用预签名交易实现，但对协作与删除密钥的要求不同。 [8] [5]

区块把交易组成一批，加入共同历史记录。在所提议的拥堵控制方案中，先确认一个承诺未来分配方式的输出。每位收款人的独立输出可以稍后通过后续交易产生，例如等网络不那么繁忙时。收款人必须掌握计划所需的数据，并能实际行使自己的权利。这不同于已经确认到其地址的普通支付，也不会让容量有限的区块拥有无限空间。 [7] [11]

钱包是接收和发送比特币的应用程序或设备。安娜可能在公布付款很久以前就准备好计划，那时还不知道未来的手续费水平。输出固定后，她不能随意减少退回钱包的金额，再把差额作为手续费给矿工。因此，构造必须预留追加手续费的方法。一个选择是妥善准备的 CPFP：后续交易花费原交易的某个输出，并提供足以激励矿工将两笔交易一起收录的手续费。另一个选择是从一开始就允许额外输入的模板。不能把这个输入直接加到只允许一个输入的模板里。Mempool 是单个节点保存的未确认交易集合；进入其中并不保证被收录进区块。 [2] [6] [10]

CTV 本身检查的是具体模板，并非能读取、任意比较所有交易数据的通用语言。它可以用于设计未来交易的分支计划，但不能与通用的递归 Covenants 混为一谈。与其他提议指令组合后，能力可能更强。因此，要看清演示究竟只用了 CTV，还是依赖一整套改动。 [1] [2]

在 2026 年 10 月 17 日的核查中，BIP119 状态为 Draft，即仍在完善中的提案。它将为 OP_NOP4 增加新的检查功能；这条指令目前在区块验证时不起作用。收紧共同规则的这种方式称为 Soft Fork。但文档本身并未规定激活方案。发表 BIP 并不意味着 opcode 已成为实际执行约束的指令；代码、开发者支持或演示钱包也不能证明 Bitcoin 主网 mainnet 已经执行它。因此，每个演示都需要说明使用的网络、规则和依赖的其他提案。 [1]

在规则尚未执行之前，仅仅把它写进脚本并不能获得预期保护；共识规则与 mempool 拒绝策略不同。即使在支持 CTV 的环境中，只有一个强制模板且没有其他花费路径，也可能使资金不足的输出无法花费。不过，新转入的一小笔资金不会自动冻结其他已经正确注资的 UTXO。安全设计必须检查金额、手续费、备份以及全部恢复路径。 [1] [4] [6]