协议演进 / BIP/比特币改进提案 / BIP-106
BIP-106
用上一难度周期的实际区块大小——第二方案再加上矿工手续费收入的变化——自动决定区块大小上限翻倍、减半或按比例调整，取代固定 1MB。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-106 |
|---|---|
| 标题 | Dynamically Controlled Bitcoin Block Size Max Cap |
| 作者 | Upal Chakraborty <[email protected]> |
| 指定日期 | 2015-08-24 |
| 层级 | Consensus (hard fork)（共识（硬分叉）） |
| 类型 | Specification（规范类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/106 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki |
二、放在哪一族
2015 年区块大小之争中的“动态上限”一族，与 BIP-105、BIP-107 是近亲，但信号来源不同：
BIP-105：信号来自矿工付费投票，取中位数
BIP-106：不投票——信号直接来自链上已经发生的事实，即上一周期的实际块大小（第二方案再看手续费总额）
BIP-107：先按时间表扩容，之后按“块有多满”小步上调
原文在“考虑过的其他方案”中列出对照对象：Jeff Garzik 的 BIP-100、Meni Rosenfeld 的弹性区块上限（elastic block cap）、Gavin Andresen 的 BIP-101、Pieter Wuille 的 BIP-103，以及 Poon 与 Dryja 的闪电网络论文。它的立场是：上限应当像难度一样，能随需求自动升降。
三、它要解决什么
动机只有一条主线：采用率上升，交易量必然增长；若 1MB 上限不改成能随网络需求自我调整的弹性上限，采用就会受阻，比特币的增长会被“卡住”（choke up）。原文附了一张自创世以来的平均区块大小变化图作为背景。
与 BIP-105 担心“矿工投票可被操纵”不同，BIP-106 的出发点更简单：需求会自己体现在块的大小里，那就让上限跟着实际块大小走，不需要任何人表态。
四、规则本身
原文给出两个并列方案，二选一。
4.1 方案一：只看上一周期的块大小
考察上一个难度周期中前 2000 个区块的大小：
- 若其中超过 50% 的区块，其大小超过当时 MaxBlockSize 的 90%，则 MaxBlockSize 翻倍；
- 否则，若其中超过 90% 的区块，其大小低于当时 MaxBlockSize 的 50%，则 MaxBlockSize 减半；
- 其余情况，MaxBlockSize 不变。
设计类比难度调整：块持续接近上限说明需求真实存在，块普遍很空则上限下调，避免少数区块就扫空内存池。
4.2 方案二：块大小与手续费一起看
把最近 2 个难度周期切成前后两段各 2008 个区块（原文注明：后一段实际包含前一难度周期的 8 个区块），分别汇总两段的区块大小总和与交易手续费总和。只有当三项条件同时成立时才调整：
- 提高：前 4016 个区块的平均大小超过 MaxBlockSize 的 50%，且后一段手续费总额大于前一段、后一段区块大小总和大于前一段——新上限 = 后一段区块大小总和 × 旧上限 ÷ 前一段区块大小总和（按实际增长同比例放大）；
- 降低：平均大小低于 MaxBlockSize 的 50%，且手续费与块大小总和都下降——按同一公式同比例缩小；
- 其余情况，不变。
加手续费条件的目的，是保住挖矿收益的稳定性：手续费收入没有增长、没有形成手续费压力时，就不放行扩容。原文认为，因为调整幅度与平均块大小的变化同比例，任何一方都很难操纵（game）这个机制。
4.3 兼容性与部署
- 这是硬分叉改动：做完整区块验证的运行者必须在激活前升级，否则可能拒绝包含大于 1MB 区块的链。
- 部署方式只写了一句：若达成共识，可在一个未来的、难度将发生变化的区块高度部署。原文没有给出具体的投票阈值、信号位或时间表。
五、谁必须动
普通持币人：无直接操作；交易格式与地址不变。
钱包开发者：原文未提出钱包侧的专门改动。
全节点与矿工：必须升级到新共识规则——按周期统计块大小（与手续费）并执行新的上限；不升级的完整验证节点面临拒绝新链的风险，原文在兼容性一节明确写了这一点。
共识层：固定常数 1MB 被一个由历史链上数据计算出的变量取代，且上限可以向下调——向下调这一点在同族提案中并不多见。
六、现在算不算数，以及一个常见误读
状态为 Closed（已关闭）。它没有在比特币主网激活。原文只给出了两个候选公式而没有收敛为一个确定规范，部署一节也只有一句原则性表述；作为档案，它记录的是“让上限像难度一样自动调整”的思路，而不是一套曾被执行的规则。
常见误读：
“BIP-106 就是让区块大小翻倍的提案。”
不对。翻倍只是方案一在“多数块超过上限 90%”时的一个分支结果；同一方案在块普遍很空时会把上限减半，方案二更是按块大小与手续费的实际变化比例连续调整。它的主题是动态调控，不是某一次扩容数字。
七、延伸
- 阅读版：https://bips.dev/106
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki
- 相关：BIP-100 矿工投票动态上限、BIP-101 提高区块大小上限、BIP-103 随技术增长的区块大小、BIP-105 基于共识的重定目标算法、BIP-107 动态区块大小上限
- 仓库总目录：https://github.com/bitcoin/bips