协议演进 / BIP/比特币改进提案 / BIP-446
BIP-446
为 Tapscript 新增 OP_TEMPLATEHASH：把花费当前输出的那笔交易的模板哈希压入栈，使脚本能承诺‘必须由这笔交易来花’，从而替代部分预签名安排、减少二层协议的交互。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-446 |
|---|---|
| 标题 | OP_TEMPLATEHASH |
| 作者 | Gregory Sanders <[email protected]>, Antoine Poinsot <[email protected]>, Steven Roose <[email protected]> |
| 指定日期 | 2026-02-06 |
| 层级 | Consensus (soft fork)（共识（软分叉）） |
| 类型 | Specification（规范类） |
| 状态 | Draft（草案） |
| 阅读版 | https://bips.dev/446 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0446.md |
二、放在哪一族
交易模板承诺一族。它与 BIP-119 的 OP_CHECKTEMPLATEVERIFY 是近亲：都让一枚输出承诺“花费它的交易必须长成某个样子”。区别在形态——前者是校验型操作码，本 BIP 是把哈希压上栈，脚本可以拿这个哈希继续做比较、签名等组合运算。
血缘与组合关系：
BIP-341：Taproot；模板哈希复用它的签名消息预计算字段
BIP-342：Tapscript；本 BIP 只在这个环境里定义新操作
BIP-340：其带标签哈希（tagged hash）被本 BIP 沿用，新标签为 TemplateHash
BIP-448：打包部署提案，把本 BIP 与 OP_CHECKSIGFROMSTACK、OP_INTERNALKEY 一起提出激活
三、它要解决什么
二层协议里，“下一笔交易必须恰好是这一笔”这种约束，今天普遍靠预签名交易模拟：各方事先把未来的交易签好、保管好，轮到时照章广播。交互与保管都是负担，也带来风险。
原文列举的受益场景：
- 闪电网络：可免去在 commitment_signed 消息里为每个 HTLC 传递、保存签名的做法——把 HTLC 交易直接承诺进承诺交易的 HTLC 输出，是对现行 2-of-2 多签安排的直接替代；
- Ark：接收一枚 VTXO 可以做到非交互（non-interactive）；
- LN-Symmetry：减少实现所需的交互轮次（roundtrips）；
- Discreet Log Contracts（DLC）：原文称之为显著的优化。
共同点是：用脚本内的一次哈希承诺，替掉“所有参与方预先签名”这一整套交互流程，协议因此更简单、更安全，有时还明显更省。
四、规则本身
4.1 操作语义
OP_TEMPLATEHASH 在 Tapscript 执行环境中重新定义 OP_SUCCESS206（0xce）。执行时，把当前上下文中“花费本输出的那笔交易”的模板哈希压入栈，脚本继续执行。它不像校验型操作码那样自己判成败——判不判、怎么判，由后续脚本决定。
4.2 模板哈希的组成
模板哈希是对下列字段拼接后做标签为 TemplateHash 的带标签哈希（构造沿 BIP-340、BIP-341），数值字段为 4 字节小端：
交易层面的数据：
- nVersion（4 字节）：交易版本；
- nLockTime（4 字节）：交易锁定时间；
- sha_sequences（32 字节）：全部输入 sequence 序列化的 SHA256，按 BIP-341；
- sha_outputs（32 字节）：全部输出以 CTxOut 格式序列化的 SHA256，按 BIP-341。
关于本输入的数据：
- annex_present（1 字节）：有无 annex，按 BIP-341 定义；
- input_index（4 字节）：本输入在输入向量中的下标，从 0 起；
- 若有 annex，再加 sha_annex（32 字节）：annex 的 SHA256。
无 annex 时共哈希 77 字节，有 annex 时 109 字节。原文指出，这比其他既有操作所需的哈希量还要少，且预计算子字段的复用避免了二次方级哈希。
4.3 故意不承诺的字段
模板哈希刻意不纳入 BIP-341 签名消息中的若干字段，原文逐项给了理由：
- hash_type、spend_type：本操作的输入是固定的，不需要调节哈希组成的机制；ext_flag 恒为 0，故直接承诺 annex_present；
- sha_prevouts、sha_scriptpubkeys：若承诺它们，而哈希本身又写在被花的输出里，会形成哈希循环；承诺其他输入还会带来与输入数成二次方的数据量，并妨碍在同一笔交易里花两枚带模板承诺的币。不承诺具体花哪些币，也留出了出错后补币补救的余地；
- sha_amounts：对可重绑定签名而言承诺金额的用处有限，又会让“多付了钱”从‘多余部分变手续费’恶化为‘输出永远花不出去’，并同样妨碍出错补救。
一句话：承诺的是交易的样子（版本、锁定时间、序列、全部输出、annex 有无），不是这笔交易花的是谁的币、花了多少。
4.4 与 OP_CHECKTEMPLATEVERIFY 的关键区别
- 只定义于 Tapscript，不碰 legacy 脚本，风险面更小；且 Tapscript 有 OP_SUCCESS 这类更强的升级位，才能把哈希压上栈，而不是只能做不改栈的断言校验——压栈使它能作为可重绑定签名的构件高效组合；
- 不承诺各输入的 scriptSig：Taproot 的 scriptSig 必须为空，在单输入情形下同样能达到 txid 稳定；
- 承诺 annex（或其不存在）：与既有承诺 annex 的操作保持一致，也为 annex 将来的含义留出前向兼容。
五、谁必须动
普通持币人：现在不必做任何事。本 BIP 仍是草案，未激活；普通 Taproot 收付款不涉及它。
钱包开发者：现在不必动。将来若激活，受益的主要是二层协议的钱包与节点软件，普通钱包无需为收付款改变行为。
二层协议开发者：这是主要受众。闪电、Ark、LN-Symmetry、DLC 等构造可用模板哈希替代部分预签名流程；设计时必须记住 4.3 的边界——它不承诺 prevout 与金额，需要这些保证的场合要另行安排。
全节点与矿工：若将来激活，需按新语义执行 0xce。原文指出：给 OP_SUCCESS 赋予含义只是收紧区块验证规则，不存在“新规则下有效、旧规则下无效”的区块，故与未升级软件向后兼容；但作者强烈建议节点运营者升级，以完整验证全部共识规则。
共识层：只改 Tapscript 中一个 OP_SUCCESS 操作码，不动 legacy 脚本与其他环境。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案）。今天的主网 Tapscript 中 0xce 仍是 OP_SUCCESS：执行到即成功，更不会把什么模板哈希压上栈。原文给出实现链接与两套测试向量文件，但“有实现、有测试向量”不等于已部署；它何时、以何种组合激活，要看 BIP-448 这类打包提案的后续进展，本页不臆测。
常见误读：
“OP_TEMPLATEHASH 就是 OP_CHECKTEMPLATEVERIFY 换了个名字。”
不对。两者同族但不同形：BIP-119 是校验型——脚本把期望哈希与计算结果比对，不符即失败，且适用于包括 legacy 在内的语境、还承诺 scriptSig、不承诺 annex；BIP-446 只在 Tapscript 中把哈希压上栈，之后怎么用由脚本决定，承诺 annex 而不承诺 scriptSig。把它当 CTV 读，会在可组合性与承诺范围两头都读错。
七、延伸
- 阅读版：https://bips.dev/446
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0446.md
- 相关：BIP-119 OP_CHECKTEMPLATEVERIFY、BIP-341 Taproot、BIP-342 Tapscript、BIP-448 打包部署提案
- 仓库总目录：https://github.com/bitcoin/bips