BIP-1
流程层｜Closed（已关闭）｜规定改进提案怎么写、怎么编号、怎么公开争论与留档。它不改比特币协议本身，而是给后来所有 BIP 定规矩的说明书。
一、档案卡
| 编号 | BIP-1 |
|---|---|
| 标题 | BIP Purpose and Guidelines |
| 作者 | Amir Taaki <[email protected]> |
| 指定日期 | 2011-09-19 |
| 类型 | Process（协作流程） |
| 状态 | Closed（已关闭） |
| 接替文档 | Proposed-Replacement: BIP-2 |
| 阅读版 | https://bips.dev/1 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki |
二、放在哪一族
BIP-1 是流程族的起点，相当于比特币改进提案体系的“宪法初稿”：定义 BIP 是什么、分几类、怎么投稿、状态怎么流转、编辑做什么。
它已被 BIP-2（2016，Luke Dashjr）替换；现行流程是 BIP-3（Updated BIP Process，状态 Deployed）。分层分类规则见 BIP-123。
读 BIP-1 是为了理解整套提案制度从何而来，以及为什么：仓库收录 ≠ 社区背书 ≠ 已经激活。
三、它要解决什么
2011 年前后，比特币没有公司、没有产品负责人、也没有正式路线图。开发者越来越多，改动若只靠邮件列表和论坛口头传递，容易出现：
- 各家实现各写各的，互不兼容；
- 同一想法反复争论、没有统一留档；
- 后来的人不知道某项设计当初为什么被接受或被否决。
Amir Taaki 借鉴 Python 的 PEP（Python Enhancement Proposal），提出：把想法写成公开设计文档，编上固定编号，放进版本库。仓库里的修订历史，就是这份建议的完整历史记录。
BIP 被定位为三件事的主要机制：
- 提出新功能：用规范语言写清要改什么；
- 收集社区意见：公开讨论，作者负责争取共识，并记录反对意见；
- 记录设计决定：为什么选这条路、放弃了哪些替代方案。
作者（champion）负责推进共识；编辑只做行政与文字工作——编号、格式检查、入库——不当技术裁判，更不能强迫全网采用。
四、规则本身
4.1 三类 BIP
Standards Track（标准类 / 共识规则）
描述会影响大多数或全部比特币实现的改动，例如：网络协议变更、区块或交易有效性规则变更、影响应用互通性的任何新增或修改。SegWit、Taproot 等升级都属于这一脉络。标准类 BIP 由设计文档与参考实现两部分组成；在标为 Final 之前，必须提供实现（代码、补丁或指向实现的 URL）。
Informational（信息类 / 使用说明）
描述设计问题，或向社区提供一般性指南与信息，但不提出必须采用的新功能。信息不一定代表社区共识或推荐，用户与实现者可以忽略，也可以遵循。
Process（流程类 / 协作流程）
描述比特币周边的流程，或提出对流程的修改。作用范围不在协议本身：投稿规范、决策流程、开发工具与环境等。流程类通常需要社区共识，用户一般不能像对待信息类那样随意忽略。任何“关于 BIP 本身的 BIP”（meta-BIP）都属于流程类。BIP-1 自己就是流程类。
4.2 工作流要点
- 必须有 champion（牵头人）：写文档、引导讨论、争取共识。
- 先公开探路：到 bitcoin-dev 邮件列表（或技术论坛）确认想法是否值得写成 BIP，避免重复已被否决的方案，也避免只适合作者个人、不适合多数使用场景的想法。
- 小改动不必写 BIP：只需提交补丁到相应项目的工作流即可。
- 一份 BIP 只讲一个核心想法：越聚焦越容易成功；拿不准就拆成多份。
- 作者不得自己编号：先用临时别名，例如 bip-johndoe-infinitebitcoins；由编辑分配正式编号。
- 编辑可拒绝的情形：重复劳动、不守格式、过于发散或空泛、技术上站不住、缺乏动机说明或未处理向后兼容、明显违背比特币设计哲学。编辑不得无理拒绝。
- 标准类必须有参考实现：才能进入 Final；实现应包含合适的测试与文档。
4.3 状态（BIP-1 当时的体系）
Draft（草稿）→ Accepted（已接受）→ Final（完成）；也可 Deferred（搁置，可再回到 Draft）、Rejected（否决）、Withdrawn（撤回）、Superseded（被取代）。
部分信息类与流程类可以长期为 Active（长期有效），因为它们本就不是“做完就结束”—— BIP-1 当年就是例子。
现行 BIP-3 已将状态收束为约四档：Draft、Complete、Deployed、Closed。阅读旧文档时，以仓库当前标注为准。
4.4 一份合格 BIP 应包含的部分
- Preamble（文件头）：编号、标题、作者、状态、类型、创建日期等元数据
- Abstract：约 200 字说明要解决的问题
- Copyright：公有领域或 Open Publication License
- Specification：语法与语义，细到可做出可互操作的实现
- Motivation：为何现有协议不够用；缺动机可直接被拒
- Rationale：设计取舍、替代方案、相关工作、社区共识与主要异议
- Backwards Compatibility：不兼容点及其处理办法；缺此节可被拒
- Reference Implementation：Final 前必须完成
4.5 文件头格式
必填（按顺序）：BIP、Title、Author、Status、Type、Created。
可选：Discussions-To、Post-History、Replaces、Superseded-By、Resolution（标准类需要）。
正文使用 MediaWiki 或 Markdown。辅助文件命名为 BIP-XXXX-Y.ext。
五、谁必须动
普通持币人：无直接变化。不会因此改变交易格式或地址。
钱包与矿工：同样不必因 BIP-1 本身升级。
开发者与实现维护者：投稿有了固定格式与公开仓库；真正改协议仍需另写标准类 BIP，并靠节点自愿采用。
编辑：负责编号、格式、入库与状态维护，不裁定协议是否“应该”改变。
关键原则：仓库收录是出版行为，不是背书；Final/Deployed 也不等于全网已执行。经济多数与节点软件的实际选择，才决定协议是否真正变更。
六、现在算不算数，以及一个常见误读
BIP-1 状态为 Closed，已被 BIP-2 接替，现行流程以 BIP-3 为准。它仍值得读，因为解释了整套制度的设计意图：公开、可追溯、作者负责共识、编辑只管行政。
常见误读：
“ BIP 被编号 / 被接受 = 全网必须升级。”
不对。BIP-1 明确区分“把话说清楚、留下记录”与“谁有权下令改协议”。节点是否升级始终是自愿的；标准类改动最终要看实现与网络是否真正采用。
七、延伸
- 阅读版：https://bips.dev/1
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki
- 后续：BIP-2（修订流程）、BIP-3（现行流程）、BIP-123（分层分类）