比特币是去中心化的和开源的，这意味着没有集中的权限来决定协议升级。因此，任何人都可以参与到其代码修改，变更的议程中。本文介绍了什么是BIP（Bitcoin Improvement Proposals，比特币改进提案），以及详细展示BIP协议的治理是如何运作的？

为什么需要BIP？

在比特币发展早期，并没有一个让社区成员共同讨论、提出有效建议并得到认可、实施的系统的存在。

比特币的维护与迭代更新落到了核心开发者的身上。中本聪在初始阶段为比特币写下了基础的框架，但系统可能出现的运行问题以及为了适应现实需求所要进行的升级却是无可避免。早期出现这些情况时，往往是中本聪自己进行处理，当中本聪退出后，维护与迭代更新的任务落到了当初的比特币核心开发者身上。

由于社区的扩展，社区讨论将会导致技术分歧。当时比特币核心开发者只是一个小团体，有要修改的地方就直接内部讨论并发布，但当社区发展壮大时，这种方式就容易引发技术分歧，有开发者认为比特币核心团队对比特币协议有过多的控制，这将会是导致比特币失败的最终原因。因此，提出了BIP（比特币改进建议）。

BIP的两个版本

2011年8月19号BIP0001开始实施。BIP（Bitcoin Improvement Proposals，比特币改进提案），这个概念最先由Amir Taaki在2011年8月19号提出，这个提案也就成为了第一个BIP。BIP0001定义了BIP的基本流程。

2016年2月3日 Luke Dashjr 提出BIP0002。BIP0001基本满足当时社区对于开发流程正式化的需求，但由于其中很多的细节没有描述详细，且有部分的规范已经过时，而BIP0002在此基础上进行迭代，最后得到实施并替代了BIP0001成为目前在使用的BIP规范。

提交BIP前应该做什么？

当你有了一个具体的针对比特币的新的想法后，确认你的想法适用于BIP，一些小的更新或者漏洞修复，直接到特定的项目开发提交问题即可，并不足以成为一个BIP。

首先，在各大相关论坛上公开验证想法，以节省时间。在编写BIP之前，先在适当的地方公开想法，可以是比特币邮箱列表（bitcoindev@lists.linuxfoundation.org）或Bitocoindev IRC或相关技术论坛，让大家提出意见。这样的好处在于可以节省自己的潜在时间，能在大量的工作之前发现自己的想法是否存在问题。

另外，需要询问的是这个想法是否是之前没有人提出过的。很多人都提出过很多关于比特币的想法，但最后都因为种种原因被否决了。所以你的想法可能之前就有人提过出类似的内容但没有成功被实现。如果存在这种情况，发掘出没有被实现的原因是什么，如果不能解决则不要花费太多时间在注定要被拒绝的事情上了。

同时，需要确保的是你的想法是适用于整个社区的。有些时候这个想法自己看起来不错，但是并不适用于比特币社区的大部分人，这种想法最终也是要被拒绝的。

BIP的格式要求

当你在社区发表了这个想法并觉得有被接受的可能性时，你就可以着手撰写BIP草案了。但是，BIP有严格的格式要求，不根据格式撰写会被直接退回。

一个合格的BIP草案需要包含以下内容：

• 序言：包含BIP的基本数据的序言，需要按照特定格式写

• 摘要：对要解决的技术问题的简短的描述（约200个字）

• 版权：需要根据特定版权条款获得明确许可

• 动机：清楚地解释为什么现有的协议不足以解决本BIP要解决的问题

• 规范：技术规范应足够详细地描述任何新功能的语法和语义。

• 原理：描述设计的动机和为什么要做出这个特定的设计决策用以补充规范

• 向后兼容：所有引入向后不兼容的BIP都必须包含描述这些不兼容及其严重程度的部分。BIP必须写明作者建议怎样处理这些不兼容问题。如果没有足够的向后兼容性论述，BIP提交可能会被直接拒绝。

• 参考实现：参考实现必须在赋予“最终”状态之前完成，但是在BIP被接受之前不需要完成。

一个合格的BIP草案还需要注意格式

序言格式需要注意：

• BIP: <BIP number, or "?" before being assigned> ?//BIP编号，如果是草案阶段就填写“？”

• * Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | ? ? ? ? ? ? Applications>?//记录BIP作用于哪个层级，在BIP123有不同层级的定义

• Title: <BIP title; maximum 44 characters> ?//BIP的标题，最多是44个字符

• Author: <list of authors' real names and email addrs> ? //作者的名字与电子邮件地址

• * Discussions-To: <email address> ?// 讨论BIP的邮件列表地址

• * Comments-Summary: <summary tone>??//BIP得到的评论的总结

• Comments-URI: <links to wiki page for comments> ?//查看BIP评论的wiki地址

• Status: <Draft | Active | Proposed | Deferred | Rejected |

• Withdrawn | Final | Replaced | Obsolete> ?//标明当前的BIP处于什么状态

• Type: <Standards Track | Informational | Process> ?//标明BIP所属类型

• Created: <date created on, in ISO 8601 (yyyy-mm-dd) format> ?//BIP被分配标号的日期

• License: <abbreviation for approved license(s)> ?//使用的许可证书

• * License-Code: <abbreviation for code under different approved license(s)> ?//许可码

• * Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive> ?//发布的时间（发布到比特币邮件列表）

• * Requires: <BIP number(s)> ?//所依赖的BIP编号

• * Replaces: <BIP number> ?//代替了的BIP编号

• * Superseded-By: <BIP number> ?//被哪个BIP所替代了

除带*号的内容其他都是必需的

BIP的附件格式需要注意。BIP可能包括图表等附件，附件应包含在该BIP的子目录中，且必须命名为BIP-XXXX-Y.ext，其中“ XXXX”是BIP编号，“ Y”是序列号（从1开始），“ ext”被实际的文件扩展名替换（例如“ png” ”）。

BIP的审核流程

BIP草案撰写完毕后，就需要将完整的文档提交到比特币开发邮件列表，所有订阅了该邮件列表的人都能接收到你的提案。

在社区中将BIP草案公开，对完整提案再次进行讨论。此时你需要针对这个BIP草案再次在社区进行公开讨论。上次进行的公开讨论仅仅是一个想法，本次是针对完整的提案进行讨论。

对BIP草案进行再次修订，发送给编辑。尝试引导社区成员成为你的BIP的拥护者并积极听取社区成员的意见，然后对你的BIP进行再次修订。当你感觉准备好了，就可以把你的BIP发送给BIP编辑了。当前的BIP编辑是Luke Dashjr，可以通过luke_bipeditor@dashjr.org联系到他。

BIP编辑的职能

当BIP编辑收到新的BIP草案之后，他会执行以下操作：

• 检查BIP整体是否准备就绪。已经准备就绪的BIP有两个特性：完整与健全。就是说草案的内容是完整的满足规范的且没有漏洞、经得起推敲的。

• 检查标题是否准确描述了内容

• 检查是否有事前发到比特币开发邮件列表进行公开讨论

• 检查动机是否有被完整描述、向后兼容性是否有被解决

• 检查是否按照规范正确分配序言中的Layer标签

• 检查许可证是否在规定范围内

如果BIP编辑认为你的BIP还没有准备好，会说明原因并发回给你，你针对BIP编辑给的说明重新编辑修订后，再次发送即可。

经过完善后，你可以拉取请求提交到BIPs git 仓库中。收到拉取请求后，BIP编辑将会进行以下操作：

• 给你的BIP分配一个BIP编号，这样你的BIP算是正式诞生了！

• 标记你的BIP类型（标准跟踪、信息性、流程）

• 合并你的拉取请求，此时BIP就加入了BIP仓库

• 在README.mediawiki中列出你的BIP，大家都能方便查看动态

到此为止，你的BIP会再次公开，从而得到进一步的社区反馈。

BIP的类型共有三种：

• 标准跟踪BIP：描述了影响大多数或所有比特币实现的任何更改，例如网络协议的更改，块或交易有效性规则的更改，或任何影响使用比特币的应用程序互操作性的更改或增加。

• 信息性BIP：描述了比特币设计问题，或向比特币社区提供了常规准则或信息，但未提出新功能。信息性BIP不一定代表比特币社区的共识或建议，因此用户和实施者可以自由地忽略信息性BIP或遵循其建议。

• 流程BIP：描述了围绕比特币的流程，或提出流程的更改（或其中的事件）。流程BIP类似于“标准跟踪BIP”，但作用于比特币协议本身以外的区域。流程BIP可能会提出实施方案，但不会是针对比特币的代码库的；他们经常也需要社区的共识；与信息BIP不同，它们不仅仅是建议，而且用户通常不能随意忽略它们。过程，指南，决策流程的更改以及比特币开发中使用的工具或环境的更改这些都是属于流程BIP。

BIP的最终实现流程

当你的BIP通过审核并并入到BIP仓库后，抓紧时间推进你的BIP，毕竟自己的想法得以实现并作用于社区会给你会带来很大的成就感。

流程BIP和信息BIP将会讨论月余时间，若无反对意见，就即可生效。那么就如果是流程BIP、信息BIP，只要在邮件列表上讨论超过一个月后，没有任何未解决的的反对意见，我们就可以判定这个BIP达成了大部分共识，这个BIP的状态将会更改为“激活”，真正作用于比特币社区了。

而标准追踪BIP，则会更加复杂和谨慎。你的目标会是把BIP状态从“草案”变为“最终实现”。

在BIP123中把标准BIP分成了四层共五类：

• 共识层

? ? ?软分叉

? ? ?硬分叉

• 对等服务层

• API/RPC层

•  

  应用层

不同分类的BIP达到“最终实现”状态所需要达到的条件不一致。

• 软分叉BIP严格要求需要矿工的大部分投票。考虑到矿池的存在，一般情况下需要95%的绝大多数投票赞同。

• 硬分叉BIP则更严格，需要比特币整个社区的成员的采纳，特别包括使用比特币来买卖商品、存储交易比特币的人。基本上说需要比特币社区的全部成员的认可才有可能实现硬分叉，达成这样的共识是极度困难的，因此在比特币历史上没发生过真正的针对比特币的硬分叉升级。

• 对等服务BIP则要求应监控到至少1%的公共监听节点采用该BIPs一个月

• API/RPC和应用层BIP则至少由两个独立的、兼容的软件实现。

以上流程都是很复杂且漫长的，往往是多方的博弈的结果。作为BIP的拥有者，在这阶段你要做的就是不断推动你的BIP，接触更多的社区人员，努力宣扬自己的设计理念，阐述你的BIP将会如何对比特币社区产生积极的影响，争取更多的社区人员成为你的BIP的拥护者，一步一步把你的BIP实现。

BIP的状态改成“最终实现”将是对你最大的奖励。