OP_CHECKTEMPLATEVERIFY

BIP-119对其作了描述，Jeremy Rubin 于2020年1月发布了首份草案，比特币网络尚未采纳。该操作码会从堆栈中取出一个32字节的哈希，除非花费交易的模板（即其版本、锁定时间、输入数量、序列号、输出和输入索引）的哈希与之匹配，否则执行失败。您钱包里的任何功能都没有使用它，在软分叉激活之前也不会使用。

运作方式

状态： 已提出，未激活。BIP-119自2020年起一直是草案，2022年提出的一项激活方案因反对意见足够多而被搁置，且 Bitcoin Core 不含针对它的任何部署参数。

该设计沿用了一种旧的升级手法。操作码179（此前为 OP_NOP4）目前完全不执行任何操作，因此包含它的脚本对网络上的所有节点都有效。软分叉会重新定义这个字节，使已升级的节点执行检查，而未升级的节点继续放行该脚本，CLTV 通过 OP_NOP2、CSV 通过 OP_NOP3 走的就是同一条路径。

哈希涵盖哪些内容，是经过格外审慎选择的。模板涵盖输出、金额、输入数量及其序列号，但特意不含 outpoint，即被花费的币所在交易的 txid。不含它们会带来两个后果，整个提案都建立在这两点之上。第一，可以在注资交易存在之前就计算出哈希，这使得先构建一连串未来的花费、再为其注资成为可能。第二，模板不能包含对自身的承诺，因此这一限制无法被设置为无限重复，这也是支持者称其为窄范围契约（covenant）的原因。

结果是，一笔花费的 txid 在其发生之前就已知晓。钱包可以向您出具一份针对未来才会出现的付款的收据，并证明该笔币不可能有其他任何花费方式。

在哪里会遇到它

OP_CHECKTEMPLATEVERIFY 在主网上的任何地方都不运行，因此可以关注的是那些建立在自定义 signet 之上的应用，如果该操作码被激活，这些应用就会上线。

拥堵控制是被引用最多的用途。面对手续费飙升的交易所，把1,000笔提币合并支付到一笔输出中，这笔输出锁定了一棵后续付款树；每位用户日后可以展开自己的那一分支，在手续费回落时收到款项，而交易所只花费了一笔输出，而不是一千笔。保险库是第二种用途：提币必须先进入一笔带有延迟的暂存输出，如果该请求并非出自您本人，您就有一段时间窗口可以把资金追回到冷存储。支付池和非交互式闪电网络通道注资采用的是同样的先承诺、后展开的形式。

对于购买比特币的人来说，实事求是的看法是：这并不会改变任何您可以据此采取行动的事情。值得认识这个缩写，因为在关于比特币应当变成什么样的争论中它不断出现，也因为一些托管服务所宣传的保险库功能，一旦该操作码激活，就真正能够得到强制执行。

OP_CHECKTEMPLATEVERIFY vs OP_CHECKLOCKTIMEVERIFY

OP_CHECKTEMPLATEVERIFY 约束花费交易的形态，而 OP_CHECKLOCKTIMEVERIFY 约束花费何时可以发生，对资金流向不作任何限制。两者名称几乎相同，因此经常被混淆。

另一个区别是状态，也是真正重要的区别。OP_CHECKLOCKTIMEVERIFY 自2015年12月14日的区块388,381起已被强制执行，闪电网络、担保托管脚本和继承钱包每天都在使用它。OP_CHECKTEMPLATEVERIFY 从未被主网上的任何一个节点强制执行。如果某项服务告诉您，您的币受到模板承诺的保护，那么它所描述的是网络目前并不检查的东西。