提案不定义比特币：BIP-3 精简流程与它划下的边界

第一次读比特币改进提案的人几乎都会高估它的分量：文件躺在官方仓库里、编号烫金、状态写着 Final，看起来像一道圣旨。2025 年 1 月获得编号并部署的流程提案 BIP-3 专门给这种观感泼了冷水。它用一句话定义了提案的意义：BIP 不构成比特币社区共识，也不是一般性的实施建议，每份 BIP 只是作者个人递给社区的一份推荐，有些永远不会被采用，有些被部分客户端采纳，只有极少数最终改变大家共同执行的共识规则。这句话不是修辞，而是写进规范文本的分类学声明，直接决定了你读任何一份 BIP 时应该抱什么预期。

从 BIP-1 到 BIP-3：两代流程文件的接力

BIP 制度本身也是提案出来的。2011 年 Amir Taaki 参照比特币前身圈子的邮件列表传统写下 BIP-1，定义了标准类、信息类、流程类三种提案和大致工作流；2016 年 Luke Dashjr 用 BIP-2 重写了一遍，收紧了编辑审查规则。BIP-3 的作者 Murch 在动机部分说得很直白：BIP-2 写于 2016 年，其中一些安排从未获得广泛采纳，编辑角色被交了多少不该由个人裁量的判断，该精简了。于是 BIP-3 把两份前身文件的历史包袱收拢成一份更短的规则，并允许自己随流程演化继续修订。仓库首页上现在挂的正是这一份，BIP-1 与 BIP-2 的状态栏里都写着已被取代的字样。

提案不定义比特币：BIP-3 精简流程与它划下的边界图 2 — 提案不定义比特币：BIP-3 精简流程与它划下的边界 · 图 2

三条边界：仓库是什么、不是什么

BIP-3 对仓库定位的界定分三层。其一，仓库是成熟提案的出版与存档媒介，靠高可见度方便全社区阅读最新版本，透明记录每份提案的全部改动，任何成员都能完整保留一份副本。其二，仓库不追踪社区情绪，也不统计生态采用率，状态字段只是简要概览，不是投票计票器。其三，没有任何正式或非正式的决策机构管理比特币开发，也没有机构决定某份提案能否被采用。三条合在一起的实操含义是：判断一项提案的真实影响力，去看有哪些客户端实现、有多少节点部署、钱包和矿池是否跟进，而不是看仓库里那个状态词。

谁拥有提案：作者与副作者

BIP-3 把所有权写得非常具体。每份提案首先归作者所有，代表作者本人的观点；作者有义务组织讨论、回应反馈与反对意见，推进采用。考虑到写完初稿后作者可能忙不过来，这一版流程正式引入了副作者（Deputy）：由未参与起草的人担任，可以在作者缺席时代行大部分流程职责，除非被作者本人推翻。这个设计补上了一个长期灰色地带——过去很多提案在作者失联后要么僵死、要么被热心人越权代管，现在有了正式的交接通道。

文档骨架：一份合格 BIP 必须有哪些零件

格式上 BIP-3 规定了硬性结构：头部元信息块、摘要、版权，以及动机部分为必选；规范、理由、向后兼容性、参考实现、变更日志视内容而定。规范部分要求写到任何比特币项目都能据此做出互操作实现的细致程度；理由部分要交代设计灵感、考虑过的替代方案、开发过程中收到的反对意见；凡是引入不兼容的提案必须有专门章节说明不兼容的严重性和应对方法。值得玩味的是变更日志这个零件：它假定提案在标为 Complete 之后还会继续演化，把「标准是活文档」写成了模板。正文语言上允许 MediaWiki 或 Markdown 二选一，这个自由在当年也是争论过的。