协议演进 / BIP/比特币改进提案 / BIP-42

BIP-42 比特币的有限货币供给

指出按中本聪原始代码的字面行为，区块补贴会因移位运算的循环而无限重复；提议用一次远期软分叉把补贴永久归零，使总供给有限。本 BIP 目前处于已激活状态。

一、档案卡

二、放在哪一族

BIP-42 属于共识层（软分叉）一族，谈的是比特币最核心的一条规则：货币供给。它不属于 HD 钱包派生路径族（BIP-43 至 BIP-48），在编号序列里是一个独立的共识话题。

它在提案里自引的软分叉先例有 BIP-16、BIP-34、BIP-62。

读这篇要注意它的文体：指定日期是 4 月 1 日，全文以明显的戏谑笔法写成——把技术问题裹在玩笑里提出。但它指出的代码行为本身，是可以对着原始代码核对的具体事实。

三、它要解决什么

3.1 普遍信念与代码字面行为不一致

人们普遍相信比特币总量有限、最终停在约 2100 万枚。BIP-42 说：中本聪从未明说过这一点；按原始代码的字面行为，货币供给会无限增长、永不停止。

原文给出的解释是：供给被建模为每 mibillennium（1024 年）发现 4 座“新金矿”，间隔相等，每座开采 140 年。由此带来的“问题”包括：10 亿枚比特币该叫什么、用什么颜色的符号、钱包客户端何时默认切换到这个单位。提案以此反推：与其面对这些麻烦，不如提出一个“有争议的改动”——让比特币的货币供给真正有限。

3.2 问题出在补贴计算的移位运算

中本聪计算区块补贴的核心代码是：

int64_t nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210,000 blocks
// which will occur approximately every 4 years.
nSubsidy >>= (nHeight / 210000);

即：初始补贴 50 BTC，先算区块高度除以 210000（减半次数），再把补贴右移这么多位。

原文指出，这段代码依赖 C++ 规范中的未定义行为：当移位位数达到或超过数据类型位宽（64 位）时，结果在不同平台上并不保证一致。由于“新金矿间隔”恰好是减半间隔的 64 倍，而货币数据类型恰好是 64 位，在当前支持的平台上，补贴会每 64 次减半循环一次——减半到零之后，又会重新出现。

其他语言并不都有同样的行为：原文举例，Python 在移位超过整数大小时出人意料地返回 0。也就是说，不同实现按各自语言的字面行为去写，得到的供给曲线可能不同。原文的结论是：比特币需要被写清楚、定死规格，否则前路颠簸。

四、规则本身

4.1 被否掉的两种替代方案

浮点近似：用浮点近似重画补贴曲线形状。原文以玩笑口吻否掉：金融危机之后，带小数点的数字显得可疑，且整数在 Javascript 中支持不佳。

截断字符串：把比特币总量表示为字符串 "21000000000000000000000"，每约 4 年用字符串操作去掉最右边一位（原文代码实际一次去掉两位，并调侃“give or take a leap-year”）。同样被否。

这两节都是戏谑写法，作用是衬托正式提案，并非认真候选的规范。

4.2 正式提案：2214 年软分叉，补贴归零

提案本身只有一句：

• 在 2214 年 4 月 1 日实施一次软分叉，永久把区块补贴设为零；
• 结果是货币总供给被限制在 42 个“halfmillion”（half million，即 50 万）——合计即通常所说的约 2100 万枚量级，其中包括创世区块那笔实际上不可花费的 coinbase 输出。

换句话说，它要把“大家以为已经如此”的有限供给，补成一条写死的共识规则，并把生效时间推到两个世纪以后。

4.3 实现与兼容性

参考客户端的实现，原文指向 bitcoin/bitcoin 的 Pull Request #3842。

兼容性一节同样是玩笑口吻：鉴于时间尺度足够宽裕，预期所有矿工都会在 2214 年之前部署这一改动；若有少数矿工留在旧代码上，届时可能发生分叉——用原文的话说，他们之后挖到的是“fool’s gold”（愚人金）。

五、谁必须动

普通持币人：在任何现实时间尺度内都没有直接变化。提案的生效点在 2214 年，远超个人持有周期。

全节点与矿工：按提案，他们需要在 2214 年 4 月 1 日之前部署这次软分叉；届时补贴归零，仍按旧规则发补贴的区块将不被新规则节点接受。

共识层：这是本篇唯一真正触及的层面——把补贴终点从“移位运算的副产品”改为“明文规定的零”，使总供给成为规则，而不是巧合。

钱包开发者：原文没有给钱包下达任何具体的单位切换或格式义务；文中关于“10 亿枚叫什么”的讨论是引出问题的修辞，不是规范要求。

六、现在算不算数，以及一个常见误读

档案状态标注为 Deployed。需要分清两层：一是它指出的技术事实——原始补贴代码依赖未定义移位行为、按字面会在 64 次减半后循环；二是它的修法——2214 年软分叉把补贴定零。状态说的是这份文档在仓库中的归档结论，不等于“无限增发正在发生”。在现实运行的比特币规则中，补贴按减半表递减趋零，总量约 2100 万枚是全网执行的结果；BIP-42 是以玩笑形式把这件事的规格依据挑明。

常见误读：

“BIP-42 证明比特币其实会无限增发，2100 万上限是个谎言。”

不对。它证明的是：只看中本聪那一行移位代码的字面语义，供给曲线会在极远期循环，规格上没有把“有限”写死。它提出的对策恰恰是把上限正式定下来。把“代码边角的规格瑕疵”读成“今天的比特币在通胀”，是把 64 次减半之后的时间尺度（数百年后）错当成了现实。

七、延伸

• 阅读版：https://bips.dev/42
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki
• 相关：BIP-16、BIP-34、BIP-62（原文列举的软分叉先例）
• 仓库总目录：https://github.com/bitcoin/bips

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。