比特币的签名到底在签什么？传统答案是六种 SIGHASH 标志组合出来的那个哈希——规则是协议写死的，合约只能从菜单里点菜，菜单上没有的组合就永远签不出来。BIP-346 想把点菜单变成一台可调节的哈希机器：新增 OP_TXHASH，让脚本自己声明“我对交易的哪几个字段感兴趣”，算出对应哈希再决定怎么验。起草人 Steven Roose 与 Brandon Black，2024 年 4 月 24 日立项，Draft，激活方式是重定义 tapscript 语境下的 OP_SUCCESS189（0xbd）——前两个成功位分别被 BIP-443 与 BIP-345 的历史草案占过，轮到它。
执行规则简短：栈顶弹出一个叫 TxFieldSelector 的参数，校验合法后，按该选择器计算当前输入位置的 32 字节交易哈希并压回栈。真正的设计浓度全在选择器的编码里。最常用的是空选择器，零字节，语义是模板哈希的既成事实标准：纳入版本号、各输入的序列号与签名字段、全部输出、锁定时间、当前输入序号，以及所有输入输出的数量——唯独排除前序交易引用和对应锁定脚本与金额。这正是 CTV 一族研究多年的“不依赖任何历史数据的模板哈希”，所以规范干脆给空选择器安排了一个四项组合的展开定义，把惯例固化成规则。
单字节选择器是紧凑档，八位切成几段：低两位管输入怎么选，接下来的两位管输出怎么选，每段三档——不选、只选当前输入、全都要；高位段继续给版本、锁定时间这类标量字段开关。想要更细的控制可以上多字节展开，把“选了哪些输入”“选了哪些输出”“每个字段是否进哈希”逐项点名。抽象地说，这台机器的输出就是“对交易某一子集的承诺”，选择器越保守，哈希覆盖越窄，越能容忍交易其他部分变化。
它的用武之地在哪？文档给出的主线是配合 OP_CHECKSIGFROMSTACK 这类“对栈上数据验签”的积木：既然任意字段子集都能哈希，再对结果验签，效果等价于按需定制签名哈希——现有全部 SIGHASH 标志、BIP-118 提案里让引用可变而输出恒定的 ANYPREVOUT 语义，以及许多过去无处安放的组合，都能由“选择器加一次栈上验签”复现。举一个直白的场景：合约想强制“花这笔钱时输出必须长成某个样子”，传统做法要提前锁定整笔交易并互相交换预签名；有了 OP_TXHASH，直接把当前交易的输出段哈希进条件里，签名者不必预知任何历史，交互轮次从“多人先互相签好”缩到“各自独立签”。这也是第二层协议最看重的一点：去交互化。
它没有解决什么也要说清。选择器覆盖不了“引用自哪笔交易”这一维，因为模板哈希的立场就是历史无关；哈希了当前交易不等于能引用前序交易的哈希，跨交易承诺是另一族提案的题目。OP_TXHASH 也不改签名算法本身，验签仍要依赖栈上验签类操作码配合。
误区辨析。一，把它当作 CTV 换皮：它提供的粒度远超固定模板，CTV 语义只是空选择器那一档。二，以为脚本可以任意哈希交易的任意切片还不多付成本：选择器越复杂、脚本越长、验证越重，一切代价都要字节和周期来付。三，把它与交易可替换性 RBF 混谈：那是中继政策层的事，这里是共识验证层。
快速问答。问：现在主网能用吗？答：不能，tapscript 目前对 0xbd 的处理是当作 OP_SUCCESS 直接通过。问：为什么走成功码而不是新操作码？答：成功位天生向后兼容，软分叉把它“点亮”是新语义提案的通行做法。问：与 BIP-446 OP_TEMPLATEHASH 谁更广？答：TEMPLATEHASH 固定一个模板档位，TXHASH 把档位做成可调参数。
一条对照账帮助记忆：把交易想象成一张表格，SIGHASH 标志是六张固定复写纸，只能整张或部分盖章；OP_TXHASH 则允许你用荧光笔先涂出想固定的格子，再对涂色区盖章——同一支笔、同一张纸，只是从“选预设”变成了“写清单”。
风险提示：本文讨论未激活的共识提案，不构成投资建议；链上合约设计请以当期激活规则为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。