9 min readJun 3, 2020

Bitcoin is decentralized and open source, which means there is no centralized authority to determine protocol upgrades. Therefore, anyone can participate in its agenda of code changes, changes. This article describes what BIP (Bitcoin Improvement Proposals) is, and shows in detail how the governance of the BIP protocol works?
比特币是去中心化的和开源的，这意味着没有集中的权限来决定协议升级。因此，任何人都可以参与到其代码修改，变更的议程中。本文介绍了什么是BIP（Bitcoin Improvement Proposals，比特币改进提案），以及详细展示BIP协议的治理是如何运作的？

Why need BIP(Bitcoin Improvement Proposals)?

为什么需要BIP？

In the early days of Bitcoin’s development, there was no system in place for community members to come together to discuss, make effective recommendations, and have them recognized and implemented.

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

Bitcoin maintenance and iterative updates fall to the core developers. Satoshi Nakamoto wrote the basic framework for bitcoin in the initial stages, but the potential operational problems with the system and the upgrades needed to adapt it to realistic needs were inevitable. In the early days, these situations were often handled by Satoshi Nakamoto himself, and after his exit, the task of maintenance and iterative updates fell to the original bitcoin core developers.

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

As the community expands, community discussions will lead to technical disagreements. At the time, the Bitcoin Core developers were a small group and any changes they had to make were discussed directly internally and released, but as the community grew, this approach was prone to technical disagreements, with some developers believing that the Bitcoin Core team had too much control over the Bitcoin protocol, which would be the ultimate cause of Bitcoin failure. As a result, a BIP (Bitcoin Improvement Proposal) was proposed.

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

Two versions of the BIP

BIP的两个版本

BIP (Bitcoin Improvement Proposals), a concept first proposed by Amir Taaki on August 19, 2011, became the first BIP, and BIP0001 defines the basic process of BIP.

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

February 3, 2016 Luke Dashjr proposed BIP0002.BIP0001 basically met the community’s need for formalization of the development process at the time, but since many of the details were not described in detail and some of the specifications were outdated, BIP0002 iterated on this basis and was eventually implemented and replaced BIP0001 as the BIP specification currently in use.

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

What should I do before submitting a BIP?

提交BIP前应该做什么？

Once you have a new idea specific to bitcoin, making sure your idea is applicable to a BIP, some minor updates or bug fixes, just going straight to the specific project development and submitting the issue is not enough to be a BIP.

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

First, save time by publicly validating ideas in major relevant forums. Before writing a BIP, make ideas public in the appropriate place, which could be the Bitcoin email list (bitcoindev@lists.linuxfoundation.org) or the Bitocoindev IRC or a related technology forum where people can comment. This has the benefit of saving yourself potential time and being able to find out if there is a problem with your idea before a lot of work is done.

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

Besides, one needs to ask if this idea is something that no one has brought up before. A lot of ideas have been put forward about bitcoin, but they’ve all ended up being rejected for various reasons. So your idea may have been mentioned before but not successfully implemented. If this exists, uncover what the reasons are for not being realized, and if it can’t be solved, don’t spend too much time on things that are destined to be rejected.

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

Moreover, what you need to make sure is that your ideas are applicable to the entire community. There are times when the idea looks good on its own, but it doesn’t apply to the majority of the bitcoin community, and the idea is ultimately going to be rejected.

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

Format requirements for BIP

BIP的格式要求

Once you’ve published the idea in the community and feel it has a chance of being accepted, you’re ready to move on to the draft BIP. However, BIPs have strict formatting requirements and will be returned directly if not written in accordance with the format.

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

A qualified draft BIP needs to contain the following elements.

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

Preamble: a preamble containing the basic data of the BIP, to be written in a specific format

Summary: A short description of the technical problem to be solved (about 200 words)

Motivation: Clearly explain why existing protocols are inadequate to address the issues that this BIP seeks to address

Specifications: technical specifications should describe the syntax and semantics of any new features in sufficient detail.

Principle: Describe the motivation for the design and why this particular design decision was made to complement the specification

Backward compatibility: All BIPs that introduce backward incompatibilities must include a section describing the incompatibilities and their severity, and the BIP must state how the author proposes to address the incompatibilities. Without an adequate backward compatibility discourse, BIP submissions may be rejected outright.

Reference Implementation: The reference implementation must be completed before the “final” state is given, but does not need to be completed before the BIP is accepted.

序言：包含BIP的基本数据的序言，需要按照特定格式写
摘要：对要解决的技术问题的简短的描述（约200个字）
版权：需要根据特定版权条款获得明确许可
动机：清楚地解释为什么现有的协议不足以解决本BIP要解决的问题
规范：技术规范应足够详细地描述任何新功能的语法和语义。
原理：描述设计的动机和为什么要做出这个特定的设计决策用以补充规范
向后兼容：所有引入向后不兼容的BIP都必须包含描述这些不兼容及其严重程度的部分。BIP必须写明作者建议怎样处理这些不兼容问题。如果没有足够的向后兼容性论述，BIP提交可能会被直接拒绝。
参考实现：参考实现必须在赋予“最终”状态之前完成，但是在BIP被接受之前不需要完成。

A qualified draft BIP also requires attention to format.

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

The format of the preamble requires attention.

序言格式需要注意：

BIP: <BIP number, or “?” before being assigned> //BIP number, or “?” if at draft stage

* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications> //Record at which level BIP acts, different levels are defined in BIP123

Title: <BIP title; maximum 44 characters> //BIP’s title, maximum 44 characters

Author: <list of authors’ real names and email addrs> //author’s name and email address

* Discussions-To: <email address> // Discussions-BIP’s mailing list address

* Comments-Summary: <summary tone> //BIP gets a summary of the comments

Comments-URI: <links to wiki page for comments> //View the wiki address for BIP comments

Withdrawn | Final | Replaced | Obsolete> // Indicate what state the current BIP is in

Type: <Standards Track | Informational | Process> //Indicate the type to which the BIP belongs

Created: <date created on, in ISO 8601 (yyyy-mm-dd) format> //Date on which BIP was assigned the label

License: <abbreviation for approved license(s)> //license for use

* License-Code: <abbreviation for code under different approved license(s)> //license code

* Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive> //time of posting (to bitcoin mailing list)

* Requires: <BIP number(s)> //Dependent BIP number

* Replaces: <BIP number> //Replaced BIP number

* Superseded-By: <BIP number> // Replaced by which BIP

Everything else is required except what’s marked with an *.

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所替代了

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

The BIP may include attachments such as charts, which should be included in the subdirectory of the BIP and must be named BIP-XXXX-Y.ext, where “XXXX” is the BIP number, “Y” is the serial number (starting from 1) and “ext” is replaced by the actual file extension (e.g. “png”).

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

BIP review process

BIP的审核流程

Once the draft BIP has been written, the full documentation needs to be submitted to the Bitcoin Development mailing list, and all those who subscribe to this mailing list will receive your proposal.

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

Make the draft BIP public in the community and revisit the full proposal. At this point, you need to have another public discussion in the community about this draft BIP. The public discussion that took place last time was just an idea; this time it is in response to the full proposal.

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

The draft BIP has revised again and sent to the editor. Try to guide community members to become advocates for your BIP and actively listen to community members, then revise your BIP again. When you feel ready, it’s time to send your BIP to the BIP editor. Connect: luke_bipeditor@dashjr.org

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

Functions of the BIP Editor

BIP编辑的职能

When the BIP Editor receives a new draft BIP, he or she does the following.

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

Check the overall readiness of the BIP. A BIP that is ready has two characteristics: integrity and soundness. That is to say, the content of the draft is complete and meets the norms without loopholes and stands up to scrutiny.

Check that the title accurately describes the content

Check to see if there is a prior mailing to the bitcoin development mailing list for an open discussion

Check whether motives are fully described, backward compatibility is addressed

Check that the Layer label in the preamble is correctly assigned according to the specification

Check that the permit is within the regulations

检查BIP整体是否准备就绪。已经准备就绪的BIP有两个特性：完整与健全。就是说草案的内容是完整的满足规范的且没有漏洞、经得起推敲的。
检查标题是否准确描述了内容
检查是否有事前发到比特币开发邮件列表进行公开讨论
检查动机是否有被完整描述、向后兼容性是否有被解决
检查是否按照规范正确分配序言中的Layer标签
检查许可证是否在规定范围内

If the BIP editor does not think your BIP is ready, he will explain why and send it back to you, you can re-edit and revise the instructions given by the BIP editor and send it again.

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

After refinement, you can pull requests to commit to the BIPs git repository. When a pull request is received, the BIP editor will follow:

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

Assign your BIP a BIP number so that your BIP is officially born!

Mark your BIP type (standard tracking, informational, process)

Merge your pull requests, and BIP joins the BIP repository

List your BIP in the README.mediawiki so everyone can easily see what’s happening!

给你的BIP分配一个BIP编号，这样你的BIP算是正式诞生了！
标记你的BIP类型（标准跟踪、信息性、流程）
合并你的拉取请求，此时BIP就加入了BIP仓库
在README.mediawiki中列出你的BIP，大家都能方便查看动态

At this point, your BIP will be made public again for further community feedback.

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

There are three types of BIP.

BIP的类型共有三种：

Standard Tracking BIP: describes any changes that affect most or all bitcoin implementations, such as changes to network protocols, changes to block or transaction validity rules, or any changes or additions that affect the interoperability of applications using bitcoin.

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

Informational BIP: describes a bitcoin design problem or provides general guidelines or information to the bitcoin community, but does not propose new features. Informational BIPs do not necessarily represent the consensus or recommendations of the Bitcoin community, so users and implementers are free to ignore them or follow their recommendations.

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

Process BIP: Describes the process around bitcoin, or proposes changes to the process (or events in it). The process BIP is similar to a “standard tracking BIP”, but acts outside the bitcoin protocol itself. Process BIPs may come up with implementation options, but they won’t be specific to the bitcoin codebase; they often require community consensus as well; unlike information BIPs, they are not just suggestions, and users are usually not free to ignore them. Processes, guidelines, changes to the decision-making process and changes to the tools or environment used in bitcoin development are all part of the process BIP.

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

The final implementation process of the BIP

BIP的最终实现流程

After your BIP has been vetted and merged into the BIP repository, take the time to move forward with your BIP, after all, it gives you a great sense of accomplishment to have your idea implemented and working in the community.

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

Then if it’s a process BIP, an information BIP, as long as there are no unresolved objections after more than a month of discussion on the mailing list, we can determine that the BIP has reached a majority consensus, and the status of the BIP will be changed to “active”, which really works for the bitcoin community.

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

Standard tracking of BIPs, on the other hand, is much more complex and careful. Your goal would be to change the BIP status from “draft” to “final”.

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

In BIP123, the standard BIP is divided into four levels and five categories.

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

consensus level

soft fork (computing)
hard bifurcation (math.)
peer-to-peer service layer

API/RPC layer

application layer

共识层

软分叉

硬分叉

API/RPC层
对等服务层
应用层

The conditions that need to be met to reach “final realization” status are inconsistent across different classifications of BIP.

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

The soft fork BIP strictly requires a majority vote of the miners. Considering the existence of the mine pool, a 95% majority vote is generally required.

The hard fork BIP is more stringent and requires adoption by members of the entire bitcoin community, including in particular those who use bitcoin to buy and sell goods and store traded bitcoins. Basically saying that a hard fork requires the approval of all members of the bitcoin community before it is possible to achieve a hard fork is extremely difficult to reach such a consensus, so no real hard fork escalation against bitcoin has ever occurred in the history of bitcoin.

Peer-to-peer BIPs require that at least 1% of public listening nodes should be monitored to adopt the BIPs for one month

The API/RPC and application layer BIP are implemented by at least two separate, compatible software.

软分叉BIP严格要求需要矿工的大部分投票。考虑到矿池的存在，一般情况下需要95%的绝大多数投票赞同。
硬分叉BIP则更严格，需要比特币整个社区的成员的采纳，特别包括使用比特币来买卖商品、存储交易比特币的人。基本上说需要比特币社区的全部成员的认可才有可能实现硬分叉，达成这样的共识是极度困难的，因此在比特币历史上没发生过真正的针对比特币的硬分叉升级。
对等服务BIP则要求应监控到至少1%的公共监听节点采用该BIPs一个月
API/RPC和应用层BIP则至少由两个独立的、兼容的软件实现。

All of the above processes are complex and lengthy, often the result of multiplayer gaming. As a BIP owner, all you have to do at this stage is to keep pushing your BIP, reach out to more people in the community, try to spread the word about your design, explain how your BIP will positively impact the Bitcoin community, get more people in the community to become advocates of your BIP, and take your BIP step by step.

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

Changing the status of the BIP to “final implementation” will be the biggest reward for you.

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