2012 年 1 月到 4 月，比特币社区围绕「怎么让付币的人不必拿到完整脚本」爆发了同期最激烈的一场协议讨论。三条提案抢同一个问题：BIP-16 用模板化标准交易实现哈希脚本，BIP-17 发明哈希验证指令，而 2012 年 1 月 27 日立项的 BIP-18 走了第三条路——指令一个都不加，直接把交易结构的两个字段宣布过时，用三个新名字重新描述整套验证。它的最终状态是 Complete：实现过、完成使命，却没有按原文的命名体系部署上主网，是协议史上「赢了机制、输了命名权」的典型样本。
三个新字段替换两个旧字段
BIP-18 的规范部分开宗明义：scriptSig 与 scriptPubKey 从此视为过时，兼容客户端必须继续支持，但新交易类型不再使用它们。替代结构是三层：输入里的 scriptSig 换成 dataSig，内容只允许多个序列化数据元素、禁止任何操作指令——它是数据，不是脚本；dataSig 的最后一个元素单独拎出来叫 scriptCheck，执行时把它之前的所有 dataSig 元素预装载进栈（紧邻它的那个在栈顶）；输出侧的 scriptPubKey 换成 hashScriptCheck，写明允许赎回脚本的哈希，且编码被钉死为一串精确字节：先一个哈希160操作码字节、再推 20 字节、最后比对指令。这套编码的妙处在于旧客户端能原样把它读成「哈希160、20 字节、相等比较」的普通脚本，向后兼容不用打折。验证规则也逐条给全：dataSig 不得混入非推数据操作、scriptCheck 必须哈希匹配输出承诺、必须按上述预装载栈执行、必须正常结束且栈顶留真值。
签名操作按前缀计数
这份提案真正被后世继承的部分，反而是它的防滥用账本。比特币对每个区块的签名操作总数设有上限，动机写在提案里：没有限制的话，恶意矿工可以广播一个要验证几十万签名操作的块，自己抢跑算下一块，其他网络还陷在验证里。旧计数规则在 scriptCheck 框架下需要重定：OP_CHECKSIG 与 OP_CHECKSIGVERIFY 无论是否真的执行都记 1 个操作；紧跟在 OP_1 到 OP_16 后面的 OP_CHECKMULTISIG 与 OP_CHECKMULTISIGVERIFY 按前缀数字记 1 到 16 个；没有前缀的裸多签一律记满 20 个。提案附了两个算例：2 三把公钥 3 多签记 3 个；而一条把 CHECKSIG 和多签 VERIFY 塞进条件分支、前面没有数字前缀的脚本记 22 个。这套「按静态扫描、从严计数、不赖运行时分支」的思路在后续版本的签名配额规则里长期回响。
激活设计与部署结局
激活机制是同期标准件：矿工在 coinbase 输入写入 /P2SH/ 字符串，2012 年 3 月 15 日检查前 7 天区块，550 个以上（约相当于当时一周出块量的 55%）含标记，则从 2012 年 4 月 1 日起的区块强制全面验证哈希脚本；不过门槛就推迟。结局要讲清楚：主网按这套时间线激活的哈希脚本，其规范文本是 BIP-16——它同样写明「与 BIP-18 协议内容一致」，区别在于 BIP-16 不宣布旧字段过时、给出一套可直接实现的验证流程。BIP-18 的名字——dataSig、scriptCheck、hashScriptCheck——从未成为节点代码与文档的正式词汇，它的状态 Complete 记录的是「目标已被别的文本达成」。
快速问答
问：BIP-18 和 BIP-16 内容几乎一样，为何算两份提案？ 答：一份是行为规格（怎么验证、怎么算标准交易），一份是结构重述（字段改名、旧字段过时、附带计数规则），文档目标和主张范围不同。
问：hashScriptCheck 这个词今天还有人用吗？ 答：日常讨论里几乎绝迹，替代词是 redeem script 加脚本哈希前缀地址；它主要活在提案历史与老帖子里。
问：签名操作计数规则现在还是 BIP-18 那样吗？ 答：不是原样。隔离见证之后验签成本的计算被重新规定过，BIP-18 的贡献是确立了静态从严计数的原则。
常见误区
一是把 Complete 当成已部署——它表示提案流程走完、目标达成于别处，判断部署要查激活事件本身；二是把三段式结构误解为协议新增了三字节段，实际只是给既有字节位置换了说法，编码刻意保持与旧脚本一致；三是把「dataSig 禁止脚本」的纪律当成主网规则，该约束属于这份文本的理想形态，部署版 BIP-16 沿用 scriptSig 语义并加标准交易模板。
风险提示：本文为协议机制与提案历史科普，不构成投资建议；脚本类收款地址的实际可用性以当前节点政策与钱包支持为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。