“比特币支持 BIP 几？“这是个问错形状的问题——BIP 不是开相关机的功能包，一条 BIP 可能只改了地址的一个字符，另一条改了共识大规则，而且同一个 BIP 在不同版本的客户端里状态不同。真正可回答的版本是：某个 BIP 从 Bitcoin Core 哪个版本开始实现、什么时候生效。这个问题在 Bitcoin Core 源码树里有一本官方对账簿：doc/bips.md。
对账簿的体例
打开 v31.0 源码树里的这份文件，第一条是这样写的：BIP 9 的多软分叉并行部署机制自 v0.12.1 起实现，附 PR 7575 链接。往下翻，每条都遵守同一个模板——BIP 编号加规范页链接、一句”实现了什么”、加粗的版本号、GitHub 合并请求链接。部分条目还额外标注生效区块或日期，比如 BIP 16 的 P2SH 评估规则自 v0.6.0 实现、于 2012 年 4 月 1 日生效；BIP 34 要求 coinbase 写入区块高度的规则自 v0.7.0 实现，v2 区块从第 224413 区块起强制、v1 区块自第 227931 区块起不再被接受。
这行模板的四个字段各管一类问题。版本号回答”哪个客户端开始支持”；日期或高度回答”全网从什么时候开始按这条规则走”——两者能差好几年，代码先实现、网络后激活是常态；PR 链接回答”改的是哪些代码”，想读实现细节从它进去；规范页链接回答”规则的准确定义”。
三个容易读错的地方
第一，“实现了”不等于”激活了”。以 BIP 37 的布隆过滤器条目为例，对账簿写明机制自 v0.8.0 实现，同一行末尾跟着”Disabled by default since v0.19.0, can be enabled by the -peerbloomfilters option”——十一年间它从默认开着变成默认关着。只看实现版本会得出与今天相反的结论。
第二，有些条目记录的是修 bug 而不是新功能。BIP 42 那条写的是：会在第 13440000 区块后错误恢复补贴发放的缺陷，在 v0.9.2 通过 PR 3842 修掉。这类条目存在的意义是让”哪个版本安全”有据可查。
第三，这本账簿是 Core 视角的实现记录，不是 BIP 状态机。BIP 仓库里一条提案可能停在 Draft 或 Withdrawn，但只要 Core 实现了对应机制（或机制因实现而必然存在），账簿就可能收录。反过来，BIP 仓库把一条标为 Final，也不代表 Core 已经动手。查提案流程状态要回 BIP 仓库本体，查”我们的软件到底做了什么”看这本账。
实战查法
举两个常见场景。场景一：有人在讨论里说”比特币从很早就要求交易费了？“，可以按账簿确认 BIP 相关的费率政策其实是各版本默认参数渐进调整，账簿没有”强制费”条目——这个说法经不起对账。场景二：钱包开发者要判断多高的客户端版本能收 P2WSH。账簿上 BIP 141 隔离见证的条目写明自 v0.16.0 实现并于第 495001 区块生效，这就是能直接引用的下限。
日常运维里这本账还能防一类舆情：某个 BIP 被媒体渲染成”比特币已升级”，先翻账簿看实现版本与激活高度，很多”升级新闻”会当场还原成”三年前就激活的旧规则被重新炒热”，或者”还没实现的提案”。
账簿的维护纪律
这本对账簿不是某个论坛帖子的搬运：每条对应的是已经合并进主干的 PR，链接指向真实的合并记录，这意味着它能扛住”我印象里是 X 版本”的争论——对账方式是顺着 PR 号翻到提交、顺着提交看生效开关。它也随版本滚动更新：新版本发布说明里出现协议相关新条目时，维护者会同步补进账簿，所以读旧版本源码树里的账簿只能回答”截至那个版本”的事实。引用时把版本号带进句子里——“v31.0 源码树 doc/bips.md 记载”比”官方文档说”更准确，也方便对方复核你读的是哪一版。若两个版本的账簿在某条上有出入，差异本身通常就是那次改动的时间戳。
风险提示：本文为协议资料查法说明，引用历史参数请以原文为准；本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。