协议演进 / BIP/比特币改进提案 / BIP-3
BIP-3
现行 BIP 流程：状态收束为 Draft、Complete、Deployed、Closed 四档，类型改称 Specification／Informational／Process，仓库只做出版与留档，不裁定采用。本 BIP 目前处于已部署状态。
一、档案卡
| 编号 | BIP-3 |
|---|---|
| 标题 | Updated BIP Process |
| 作者 | Murch <[email protected]> |
| 指定日期 | 2025-01-09 |
| 讨论日期 | 2024-05-13 |
| 类型 | Process（流程类） |
| 状态 | Deployed（已部署） |
| 替代 | BIP-2 |
| 依赖 | BIP-123 |
| 阅读版 | https://bips.dev/3 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0003.md |
二、放在哪一族
流程族的现行版本，第三代。链条是：BIP-1（2011，初版）→ BIP-2（2016，修订版，已 Closed）→ BIP-3（替代 BIP-2，状态 Deployed）。它依赖 BIP-123 的分层分类：文件头里的 Layer 取值仍按 BIP-123 定义。
今天往仓库提交新提案、判断一份旧 BIP 的状态是什么意思，都以 BIP-3 的定义为准。文件头标注版本 1.4.0，且流程类 BIP 被定义为“活文档”，可按粗略共识持续修订。
三、它要解决什么
BIP-2 写于 2016 年。原文列出的修订动机是：
- BIP-2 的若干环节没有获得广泛采用（最典型的是评论机制：实际很少有 BIP 收到评论，个别评论反而被文件头里的汇总放大了权重）；
- 分配给编辑的判断裁量太多，有些本应由作者或读者承担；
- 三类 BIP 的界定不够清楚——Standards Track 常被误解为“被推荐”，而一些影响互操作性的提案却被标成 Informational；
- 仓库的实际使用方式已经演变，流程需要与之对齐。
一句话：精简。把没人用的机制撤掉，把状态与类型减到读者真正能用的程度。
四、规则本身
4.1 先说清三件事
- BIP 是什么：为比特币提出的改进提案，主题是支持与扩展比特币货币用途的信息与技术；多数 BIP 用一份自包含的技术说明讲一个新概念、新功能或新标准，少数是流程、实现指南、最佳实践或事故报告（如 BIP-50）。任何人都可以提交，但内容须有质量、不浪费社区时间；仓库范围限于不反对“比特币是点对点电子现金系统”这一根本原则的提案。
- BIP 不代表什么：单个 BIP 不定义“什么是比特币”，不代表社区共识，也不是普遍性的实施推荐；它只是作者向社区提出的一份个人推荐。有的 BIP 永不会被采用，有的被一两个客户端采用，有的最终改动了全网共同执行的共识规则。
- 仓库是干什么的：出版媒介与档案馆。它以高可见度便于全社区审议，透明记录每份 BIP 的全部修改历史；它不追踪社区情绪，也不追踪生态采用情况（除状态字段给出的简要概览外）。没有任何正式或非正式的决策机构治理比特币开发或裁定 BIP 的采用。
所有权上，每份 BIP 主要归其作者，作者负责推进讨论、回应反馈与异议；随流程推进，它逐渐变为社区共有。作者可指定 Deputies（副手）：未参与写作的代管人，在作者缺席时可代行作者职责，除非被作者推翻。
4.2 类型：Specification 取代 Standards Track
- Specification（规范类）：定义一套描述新功能或影响实现互操作性的技术规则；可以被实现、可以判定是否合规。必须有 Specification 一节，引入不兼容时必须有向后兼容一节，升 Complete 前必须有或引用参考实现与测试向量。
- Informational（信息类）：描述设计问题，或向社区提供一般指南与其他信息。
- Process（流程类）：描述比特币周边的流程或对流程的修改；常需要社区共识，对相应流程通常有约束力。
4.3 文件头与结构
每份 BIP 必须有 Preamble、Abstract、Copyright、Motivation 四部分，其余章节（Specification、Rationale、Backward Compatibility、Reference Implementation、Changelog 等）按需取舍，由作者与评审判断相关议题是否已讲透。
文件头顺序：BIP、Layer（可选）、Title（上限放宽到 50 字符）、Authors、Deputies（可选）、Status、Type、Assigned、License，可选 Discussion、Version、Requires、Replaces、Proposed-Replacement。相对 BIP-2 的改动包括：Created 改名为 Assigned（值本就是编号分配日期，旧名常引起混淆）、Post-History 改为 Discussion、Superseded-By 改为 Proposed-Replacement、删除 Comments-URI／Comments-Summary 与 License-Code、新增 Deputies 与 Version。辅助文件只能放进 bip-XXXX 子目录。
4.4 状态：只剩四档
- Draft（草案）：先在比特币开发邮件列表提出想法、做过调研、形成初稿，再向仓库开 pull request；只有编辑能分配编号，且编号只在编辑于 PR 中公开宣布后才算分配。编辑不应给明显无人感兴趣的提案编号；重复、格式不合、缺动机、未处理向后兼容、规范不清的提案还不具备编号资格。Draft 停滞满一年且作者在被联系后四周内不表示继续，任何人可提议改为 Closed。
- Complete（已完成）：作者已完成全部计划工作，确信文档清楚、完整、构成净改进，并推荐社区采用／实现／部署。规范类须附参考实现与全面测试向量。此后内容只能小改；若需实质功能变更，宁可改为 Closed 并另写新 BIP。Complete 可无限期保持，它是多数成功的 Informational BIP 的终点状态。Complete 改 Closed 只能由作者宣布（四周内有人自愿接手则保持 Complete）。
- Deployed（已部署）：Complete 之后，方案已定型、经早期采用者检验、修订停止，且有证据表明在积极使用——如已确立的项目在主网软件中发布支持、软分叉提案的激活条件已在网络上达成、或已展示粗略共识——任何社区成员都可凭证据提出。进入 Deployed 即视为定稿，除修 bug、小修订、补测试向量与编辑性修改外不应再动；规范的破坏性变更必须另写新 BIP。流程类从 Complete 升 Deployed 的标准是邮件列表粗略共识：开放讨论至少一个月、有实质参与、无人维持未被回应的实质反对。
- Closed（已关闭）：只具历史意义、不再推进或使用的 BIP 归入此档，理由须在同一次提交的 Changelog 中记录。Deferred、Obsolete、Rejected、Replaced、Withdrawn 五个旧状态统统并入 Closed，Final 与 Active 并入 Deployed，Proposed 改名为 Complete。Closed 原则上是终点；重打一份已 Closed 的想法，一般应另写新提案、新编号。
Complete 之后的每次修改都要记进 Changelog 并递增 Version（按语义版本：不兼容改动升 MAJOR，后向兼容扩展升 MINOR，其余值得注意的修改升 PATCH；升 Complete 时为 1.0.0）。流程类是活文档，可无限期按同样的粗略共识标准修订。
4.5 许可与编辑
许可改用 SPDX 表达式写在 License 字段，并在 Copyright 一节给出相符说明；可接受清单收束为 BSD-2-Clause、BSD-3-Clause、CC0-1.0、FSFAP、CC-BY-4.0、MIT、MIT-0、Apache-2.0、BSL-1.0，名单之外不可用（旧 BIP 保留原许可，只改用 SPDX 写法表达）。测试向量建议额外以 CC0-1.0 或 FSFAP 提供，以免实现者抄用时受许可牵制。
编辑的职责仍是行政与编辑性的：检查想法是否先在邮件列表提出过、是否在题、标题是否准确、格式与许可是否合规、动机与向后兼容是否处理、Layer 与 Type 是否正确，然后编号、确保列入 README、合并。原文特意写明：编辑不评估提案是否可能被采用。
五、谁必须动
普通持币人：无直接变化。这是管文档的流程，不管协议。
BIP 作者：按新文件头写作，先到邮件列表公开探路，升 Complete 时备齐参考实现与测试向量，此后用 Changelog 与版本号记录每次修改；也可指定 Deputies 代管。
编辑：按清单做形式与就绪审查、编号、合并；不裁定提案好坏与采用前景，可单方面做不动原意的编辑性修改（值得注意的要记 Changelog）。
实现者与社区：采用与否自行判断；仓库不追踪采用情况，各项目被鼓励自公布其实现的 BIP 清单（如 Bitcoin Core 的 doc/bips.md）。
六、现在算不算数，以及一个常见误读
BIP-3 状态为 Deployed，是当前生效的 BIP 流程。本站索引与解读页里的状态中文（草案／已完成／已部署／已关闭等）、状态含义，都应以它的四档定义理解；看到旧文档里的 Final、Active、Proposed、Rejected 等字样，那是 BIP-1／BIP-2 年代的旧名，已按 BIP-3 的对应关系归并。
常见误读：
“进了 bitcoin/bips 仓库、拿到了编号，就是比特币官方认可了。”
不对。BIP-3 明说：入库标准是切题且满足编辑性要求，仓库既不是比特币开发的决策机构，也不追踪社区情绪与采用情况；编号只是方便分布式讨论的引用方式，连编号本身都要等提案先在社区激起一些兴趣之后编辑才会给。
七、延伸
- 阅读版：https://bips.dev/3
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0003.md
- 相关：BIP-1（初版）、BIP-2（上一版）、BIP-123（分层分类）
- 仓库总目录：https://github.com/bitcoin/bips