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

BIP-2 BIP 流程（修订版）

修订 BIP-1 的提案流程：把三类 BIP、状态推进的可核验标准、评论机制与许可规则写清楚，让状态尽量反映真实采用情况。本 BIP 目前处于已关闭状态。

一、档案卡

二、放在哪一族

流程族的第二代文档。它替代 BIP-1，把初版里含糊的地方逐项收紧；文件头里又已标注 Proposed-Replacement 为 BIP-3，现行流程以 BIP-3 为准。

分层字段（Layer）来自 BIP-123 的分类——BIP-2 把 Layer 写进文件头模板，并注明启用本 BIP 即意味着启用 BIP-123。

读这一族要分清三件事：仓库收录、状态标注、网络实际采用。BIP-2 只管前两件的规矩，第三件由实现与用户自愿选择决定。

三、它要解决什么

BIP-1 定下了制度框架，但留了几个模糊点：

• 状态标准含糊：原文明确说，BIP-1 对 Status 的判定标准不明确、常引起困惑，结果是许多已有显著实际使用的 BIP 长期停在 Draft 或当时的 Accepted 状态，没有及时更新。
• 许可过时：BIP-1 只允许 Open Publication License 或公有领域。原文认为前者已过时、且允许作者阻止出版与衍生作品，不适合标准文档；后者在部分法域不被承认为有效的法律行为。
• 流程细节缺失：评论如何留、参考实现何时必须完成、编辑的检查清单等，都没有写细。

BIP-2 的目标不是另起炉灶，而是给同一套制度补上可核验的判定标准与更合适的许可清单。

四、规则本身

4.1 工作流（与 BIP-1 一脉相承的部分）

• 每份 BIP 须有 champion（牵头人／作者）：写文档、在合适论坛推进讨论、争取社区共识。
• 先查旧讨论，再到比特币开发邮件列表公开探路，避免重复已被否决的想法；小补丁不必写 BIP，直接走对应项目的开发流程。
• 草稿先在邮件列表讨论，再以 pull request 提交到 BIP 仓库；作者不得自行编号，入库前用别名（如 bip-johndoe-infinitebitcoins）作文件名。
• 一份 BIP 只讲一个核心想法；越聚焦越容易成功。
• 编辑不得无理拒绝；可拒绝的情形包括重复劳动、不守格式、过于发散、技术上站不住、缺动机说明或未处理向后兼容、违背比特币设计哲学。被接受的最低门槛是：描述清楚完整、构成净改进、实现（如适用）扎实且不过度复杂化协议。
• 所有权可以移交：原作者无暇、无兴趣或失联时可转给新 champion；仅仅不认同方向不是移交理由，不同意者应另写一份竞争性 BIP。

4.2 三类 BIP 与文件结构

类型仍为三类：Standards Track（标准类，影响多数或全部实现的改动，由设计文档与参考实现两部分组成）、Informational（信息类，提供指南或信息，不代表社区共识，用户可忽略）、Process（流程类，管协议之外的流程，通常需要社区共识，用户一般不能随意忽略；meta-BIP 属此类）。

每份 BIP 应包含：Preamble（文件头）、Abstract、Copyright、Specification、Motivation、Rationale、Backwards Compatibility、Reference Implementation。其中参考实现必须在标为 Final 之前完成，但不必在被接受之前完成。

文件头必填顺序为 BIP、Title、Author、Status、Type、Created、License，可选 Layer、Discussions-To、Requires、Replaces、Superseded-By 等。Title 上限 44 个字符；作者须写真实姓名与邮箱。辅助文件放进该 BIP 的子目录，或命名为 BIP-XXXX-Y.ext。

4.3 状态推进：给 Final 定客观标准

这是 BIP-2 相对 BIP-1 最大的改动。

• 状态路径：Draft 可由作者自行在 Draft、Deferred、Withdrawn 之间变更；三年无进展的 Draft 或 Proposed，经任何人请求可改为 Rejected（作者拿出实质修订后可再回到 Draft 或 Proposed）。
• Draft（或 Rejected）升 Proposed：作者认为已完成、有可用的实现（如适用）、且有推进到 Final 的社区计划。
• Proposed 升 Final：必须有反映真实采用的可核验事实，且因 BIP 性质而异：
  • 软分叉：须有明确的矿工多数以链上投票表达（例如用 BIP-9）；文档强烈建议 BIP 本身要求约 95% 的超级多数。同时，若经济体似乎愿意以“不信任”硬分叉（如更换工作量证明算法）回应，只要这种硬分叉可能获得多数支持，软分叉就不算 Final，最长观察三个月。
  • 硬分叉：须获得整个比特币经济体的采用——以比特币收款的商品与服务卖方、以及持币并会花费的人——且须以实际使用（de facto usage）表达，不能只看公开表态，也不能仅凭超级多数确立。原文特别说明：矿工、交易所、开发者本身不计入“经济体”定义，他们分别是在他人规则下出售产出、提供撮合服务、提供代码，是否计入只看他们是否同时以卖方／持币人身份参与。
  • 对等服务类：须被至少 1% 的公开监听节点采用满一个月（原文自承这一比例定得较任意）。
  • API/RPC 与应用层：须被至少两个独立且兼容的软件应用实现——只有一个实现时，谈不上“标准接口”。
• Final 不再相关时可改为 Replaced 或 Obsolete（二者等同），同样须可核验或经邮件列表讨论。
• 流程类从 Draft 升 Active：在邮件列表开放讨论至少一个月、无人维持未被回应的实质反对，即达到粗略共识（rough consensus）。

原文也强调：上述标准是用来判断状态是否如实，而不是用来反对或拒绝一份 BIP 的理由；若某 BIP 事实上已被明确采用却没满足字面标准，仍应更新为 Final。

4.4 评论机制（BIP Comments）

BIP-2 新引入评论页制度：每份 BIP 在文件头链接一个公开 wiki 评论页（放在 Comments 命名空间，如 Comments:BIP-0001），自认有资格的评审者把最终意见按“意见 –姓名, 日期”格式贴在那里；未完成的 BIP 应先在邮件列表讨论。BIP 本身可汇总评论基调写入 Comments-Summary（如 No comments yet、Unanimously Recommended 等）。原文明确：评论与状态是两个互不相关的指标，不应互相直接影响——设评论页的初衷，正是防止“有编号就被当成好主意”。

4.5 许可

新 BIP 必须在文件头 License 字段列出至少一个可接受许可，列表是“或”的关系。推荐：BSD-2-Clause、BSD-3-Clause、CC0-1.0、FSFAP；可接受但不推荐的包括 Apache-2.0、MIT、GPL-2.0+ 等；名单之外的许可不可用。代码可与正文分开许可，用 License-Code 字段。相对 BIP-1 的变化还包括：Accepted 改名为 Proposed、升 Proposed 前须有实现（如适用）、删除 Resolution 字段（去中心化系统里没有能作最终裁决的权威）等。

五、谁必须动

普通持币人：无直接变化。BIP-2 不改协议、不改交易格式。

BIP 作者：负担最重——先公开探路、收集反馈、按新文件头与许可规则写作，升状态时拿出可核验的采用证据。

编辑：订阅开发邮件列表，逐项检查标题、动机、向后兼容、Layer、许可等，做编号、合并与状态维护等行政工作；只能单方面做拼写、断链等纯编辑性修改。

实现者与软件项目：被鼓励公布自己支持哪些 BIP（如 Bitcoin Core 的 doc/bips.md），以便状态变更有据可查。

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

BIP-2 状态为 Closed。它的文件头标注 Replaces BIP-1、Proposed-Replacement 为 BIP-3；现行流程以已 Deployed 的 BIP-3 为准——状态收束为四档、评论机制废除、Standards Track 改称 Specification 等，都是 BIP-3 在 BIP-2 基础上的再修订。读 BIP-2，是为了看清“状态要反映真实采用”这条原则是怎么被写成具体标准的。

常见误读：

“一份 BIP 标成 Final，就是官方批准、全网必须执行。”

不对。BIP-2 自己在理由部分写明：BIP 流程不追求成为一种强制性的“治理”，只提供一个协作仓库，供人们自愿采用或不采用；Final 只是对“已经事实上被采用”这一现实的如实标注，不是命令。

七、延伸

• 阅读版：https://bips.dev/2
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
• 相关：BIP-1（前身）、BIP-3（现行流程）、BIP-123（分层分类）
• 仓库总目录：https://github.com/bitcoin/bips

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