协议演进 / BIP/比特币改进提案 / BIP-109
BIP-109
一次性把区块上限从 1MB 升到 2MB，同时改用准确计数的 20,000 个 sigop 上限，并新增每区块 13 亿字节的签名哈希上限；75% 算力触发，之后有 28 天宽限期。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-109 |
|---|---|
| 标题 | Two million byte size limit with sigop and sighash limits |
| 作者 | Gavin Andresen <[email protected]> |
| 指定日期 | 2016-01-28 |
| 层级 | Consensus (hard fork)（共识（硬分叉）） |
| 类型 | Specification（规范类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/109 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0109.mediawiki |
二、放在哪一族
区块大小之争中“简单改数字”一派的收尾之作。同一作者 Gavin Andresen 此前写过 BIP-101（提高最大区块大小）；同期还有 BIP-102（扩容至 2MB）。BIP-105、BIP-106、BIP-107 都在设计动态机制，BIP-109 反其道而行：
- 不投票、不看链上指标、不分阶段——只做一次性的 1MB → 2MB；
- 真正花笔墨的地方不在数字，而在两个防攻击的配套上限：sigop 的准确计数与签名哈希总量上限；
- 部署上借用 BIP-9（version bits）的思路选信号位，但阈值从常见的 95% 降到 75%。
理解它，要把重点放在“扩容的同时怎样不让 2MB 区块变成 CPU 耗尽攻击的工具”。
三、它要解决什么
原文的动机只列三条，非常直白：
- 延续当前经济政策——短期内交易量在涨，先给链上容量留出余地；
- 演练一次硬分叉网络升级（Exercise hard fork network upgrade）——把硬分叉本身当作需要练习的治理动作；
- 缓解潜在的 CPU 耗尽攻击——区块变大后，若不限制签名运算与签名哈希的成本，恶意矿工可以构造验证代价极高的 2MB 区块拖慢全网。
第三条是它与 BIP-102 等单纯改数字提案的关键区别。
四、规则本身
4.1 区块大小：1,000,000 → 2,000,000 字节
规范序列化区块的最大字节数，从 1,000,000 提高到 2,000,000。一次改完，没有后续时间表或动态公式。
4.2 sigop 上限保留 20,000，但改为准确计数
每区块 20,000 个签名运算（signature operations）的上限不变，但只计算为验证该区块而实际执行的 ECDSA 验证：
- coinbase 的 scriptSig 不计数；
- 脚本中未执行分支里的签名运算不计数；
- OP_CHECKMULTISIG 按实际情形准确计数：例如一个 1-of-20 的 OP_CHECKMULTISIG，若由执行栈顶最近的公钥满足，计 1 个；若由栈底最近的公钥满足，计 20 个；
- 涉及无效编码的签名或公钥的签名运算不计入上限。
4.3 新增签名哈希上限：每区块 1,300,000,000 字节
为计算交易签名哈希而哈希的数据总量，每区块不得超过 1,300,000,000 字节；计数规则与 sigop 的计数规则相同。原文称，这一上限选得让任何非攻击性的交易或区块都不可能触及，以尽量不影响现有挖矿与钱包软件。
4.4 激活：75% 触发 + 28 天宽限
- 独挖矿工或矿池运营者通过置起区块 32 位版本号中第四高的位（十六进制 0x10000000）表示支持。原文称选此位是为了与 BIP-9 的软分叉并行部署提案兼容。
- 第一个同时满足以下条件的区块，定义宽限期的开始：该位已置起、时间戳不晚于到期时间、且其前 1000 个区块（高度 H-1000 至 H-1）中至少 750 个置起了该位。
- 时间戳达到或超过触发区块时间戳加 28 天（60×60×24×28 秒）的区块，适用新上限。
- 75% 而非 95%，是为了尽量减少单个大矿池或矿工以意识形态反对、或受暴力与勒索威胁为由行使否决的机会；四周宽限期则是在“给足升级时间”与“保持升级紧迫感”之间取平衡。
4.5 到期：2018 年 1 月 1 日
若在 2018-01-01 00:00:00 GMT 之前未被触发，本 BIP 应视为已撤回（withdrawn）。支持者应在此日期前持续置起 0x10000000 位；此日期之后，该位可安全地复用于未来的共识规则升级。
五、谁必须动
普通持币人：使用 SPV（简单支付验证）钱包的，与此改动兼容，无需动作；运行全节点的持币人见下行。
钱包开发者：原文称签名哈希上限被设为非攻击交易不可能触及，就是为了把对现有钱包软件的影响降到最低；无需按新上限改造交易构造。
全节点与矿工：完整验证的旧客户端与此改动不兼容。第一个超过旧的区块大小上限、或超过旧式（不准确计数）sigop 上限的区块，会把旧客户端从新网络中分隔（partition）出去。矿工还须负责置位表态与在宽限期后按新规则出块。
共识层：三处共识规则同时变：区块大小上限、sigop 计数方法、新增的签名哈希总量上限。
六、现在算不算数，以及一个常见误读
状态为 Closed（已关闭）。按原文自己的到期条款，它未在 2018 年 1 月 1 日之前被触发；主网的区块容量问题后来走的是隔离见证（SegWit）等其他路径，而不是这次 2MB 硬分叉。读它应把它当作 2016 年扩容路线的一份完整标本：数字、防护、部署、到期，四件套齐全。
常见误读：
“BIP-109 就是把 1MB 改成 2MB 的一页纸提案。”
不对。改数字只有一句，规范的主体是另外两条：sigop 从粗略计数改为只计实际执行的验证，以及新增每区块 13 亿字节的签名哈希上限。若只记住“2MB”，就漏掉了它为什么强调“ rogue miners ”造出的昂贵区块——扩容与验证成本防护，在这份提案里是一件事的两面。
七、延伸
- 阅读版：https://bips.dev/109
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0109.mediawiki
- 相关：BIP-9 version bits、BIP-101 提高区块大小上限、BIP-102 扩容至 2MB、BIP-105 基于共识的重定目标算法、BIP-107 动态区块大小上限
- 仓库总目录：https://github.com/bitcoin/bips