今天比特币的脚本哈希地址来自 BIP-16 那条路线，但在 2012 年初，Luke Dashjr 的 BIP-17 一度是最被看好的实现：不新增指令语义，直接把闲置的 OP_NOP2 重定义为 OP_CHECKHASHVERIFY，花销时把真脚本塞进解锁脚本、用一个 OP_CODESEPARATOR 划出待哈希的边界。这份提案最终关闭未部署，但它留下的哈希边界思路、向后兼容处理和矿工字符串投票设计，都是理解比特币脚本升级史的重要切片。

BIP-18 是 2012 年 P2SH 路线之争里最特别的一份：它不新增操作码，而是宣布 scriptSig 与 scriptPubKey 过时，改用 dataSig、scriptCheck、hashScriptCheck 三件套重述同一件事，还顺手给签名操作定下了按前缀计数的防滥用规则。这份提案标记为 Complete，却没有以文本原样部署——最终上线的 BIP-16 在协议层与它内容几乎一致。这篇讲清它改了什么、账怎么记，以及为什么名字之争也值得写进历史。

闪电网络用 HTLC 在比特币链上中转支付，而 2019 年 3 月领号的 BIP-197 把哈希时间锁合约改装成了一份跨链借贷合同：借款人在比特币链上锁定抵押品，贷款本金在另一条链上发放，还款凭「秘密揭示」驱动，违约则在清算、竞价、扣押三段时限里分配抵押品。作者来自 Atomic Loans 项目，脚本把拒绝放款、按期还款、清算与扣押四条路径全部编进了可自动执行的 P2SH 模板。本文逐段拆解可退抵押与可扣押两条脚本的分支结构，以及五把秘密哈希如何充当合同的事件信号。

区块组装器把签名成本计数器起点设为 400 而非零，为尚未生成的 coinbase 输出预留 SigOp 预算，占八万共识上限的半个百分点。拆解预留动机、IPC 参数名与钳制边界。以 v31.0 源码为准。

BIP-441 提议一个新的 Tapscript 叶子版本 0xC2，重新启用被禁操作码、把栈对象上限提到 400 万字节，并用 BIP-440 的可变操作码预算防计算量滥用。本文讲解这套「恢复而不重蹈覆辙」的设计与它的安全边界。

BIP-124 用占位符加 BIP-32 派生路径定义脚本模板，让不同钱包对同一组派生信息产出逐字节相同的脚本，覆盖 2-of-3 多签、1-of-1 或 2-of-3、超时合约等形态。本文拆解键组的排序约定与这份 2015 年提案的未竟之处。

BIP-446 提议在 Tapscript 重定义 OP_SUCCESS206 为 OP_TEMPLATEHASH：把花掉这个输出的那笔交易的版本、锁时间、序列承诺、输出承诺等字段压成一个模板哈希压上栈，让预签名交易这种第二层拐杖可以被替代。本文拆解字段清单与 CTV 的差异。

BIP-12 在 2011 年提出 OP_EVAL 操作码：花费时把栈顶的序列化脚本反序列化并执行，让收款方决定资金的消费方式。它借道 OP_NOP1 实现向后兼容、把递归限制在两层，最终却在「数据当代码」的安全争论与执行成本中落选，位置被 BIP-16 的 P2SH 接替。本文拆解 OP_EVAL 的机制设计、一确认攻击分析与它留下的设计遗产。

比特币核心v31里getblockhash只查活动链、越界抛Block height out of range，与getblockheader接力的遍历骨架，以及重组背景下的三个实践要点。

BIP-116 提议给比特币脚本加入 MERKLEBRANCHVERIFY 操作码，让脚本承诺一棵候选分支集合，花费时只需出示实际用到的那一条。本文解释它的栈规则、与 BIP-98 验证的关系，以及它和 MAST 类提案的分野。