两百万字节的硬分叉提案：BIP-109 与其签名操作和哈希量护栏

2016 年初的比特币社区还陷在扩容争论里，Gavin Andresen 递交了 BIP-109：一次性把区块上限从 1,000,000 字节抬到 2,000,000 字节，附带两条防 CPU 耗尽的护栏。它是 2015—2017 年那段扩容史上「硬分叉阵营」最具体的一份可执行文本，最终在 2018 年元旦的自动过期条款里安静退场，状态 Closed。回头看这份提案，比看当年口水战更能理解「扩容不只是改一个数」。

先改正主：区块最大字节数一倍的提升没有任何花活，规范原文只有一句——规范序列化的区块最大字节数从一百万提到两百万。真正的功夫在两条配套限制上。第一条是签名操作计数口径的收紧：每块两万个 sigop 的旧帽保留，但只数「真正执行了 ECDSA 验证的」那部分——coinbase 的 scriptSig 不计、脚本里未执行分支（条件为假的 IF 块）里的不计、签名或公钥编码不合法的也不计。对一个 1-of-20 的 OP_CHECKMULTISIG，若验到栈顶附近的公钥就满足，只算 1 次；验到底部才满足则算 20 次。这个「按实际执行计费」的口径后来被各种扩容与反扩容方案反复引用，本质上是在把「最坏情况成本」从字面计数改成运行时计数。第二条是全新的哈希量帽：每块用于计算签名哈希的字节总量不得超过 1,300,000,000 字节，计数规则与 sigop 相同。动机很直白：交易体积和哈希次数并非线性关系，光限制体积挡不住专门构造的 CPU 耗尽攻击，必须直接给「算多少」设上限。

激活机制是这份 BIP 最有年代感的部分：矿工在区块版本号的第四高位（0x10000000）亮票，第一个亮票块若其前 1000 个块里至少 750 个也亮票，即触发 28 天宽限期；时间戳进入宽限期之后的块必须遵守新上限。过期条款写得干脆：2018 年 1 月 1 日 GMT 前没触发就视为撤回，那个票位可以放心给后来的共识升级复用。值得注意的是它没有 BIP-9 那样的期外失效检测，是纯粹的「时间闸门」思路，早于 BIP-9 成为主流之前的一代玩法。

历史给了另一种结局：2017 年 8 月主网选择的是软分叉路线的隔离见证加区块体积加权计重，2MB 硬分叉方案被搁置，BIP-109 如期过期关闭。但它留下的两件技术资产活得比提案本身久——「按实际执行数 sigop」的口径思想，和「给每块哈希计算量设总闸」的思路，都能在今天的标准交易重量、签名哈希预计算等机制里看到影子。对读者而言，它还是一枚清晰的标本：说明比特币的容量提升从来不是「矿工行使投票权就能改数字」那么简单，护栏设计、激活路径和分裂风险哪一环没算清，方案就停在纸面。

读这份 BIP 还能顺带看懂一种谈判文体。2016 年前后扩容阵营分裂为「抬帽子派」与「滚字节派」，BIP-109 把「抬帽子」写成了一份可审计的工程文件：不承诺无限增长、不设计动态算法，只做一次性翻倍，并主动给 CPU 攻击面补闸——这些保守姿态是冲着「矿工联盟强推分裂」的质疑去的。它同时保留了旧式时间闸门激活（亮票、750/1000、28 天宽限、过期自动撤回），意图很清楚：错过窗口就全体下台，不留下「半激活」的悬置状态。后来的事实是：亮票规模始终没有构成有意义的多数，2017 年主网按 BIP-9 路线的隔离见证计重方案落地，BIP-109 安静地活到了自己的过期日，然后被合上。一份失败的规格书仍然是合格的教材，它把「扩容要同时回答容量、成本模型、激活路径三个问题」写在了同一页纸上。