比特币改进提议 （Bitcoin Improvement Proposals的缩写），指比特币社区成员所提交的一系列改进比特币的提议。
具体是怎么运作的，操作流程等在BIP-0001中有表述。具体BIP-0001什么内容，本人做了翻译，如下：
BIP: 1
Title: BIP Purpose and Guidelines
Author: Amir Taaki <[email protected]>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
Status: Replaced
Type: Process
Created: 2011-08-19
Superseded-By: 2
目录 |
BIP代表比特币改进提案。BIP是一种设计文档，为比特币社区提供信息，或描述比特币或其流程或环境的新功能。BIP应提供该功能的简明技术规范和该功能的基本原理。
我们希望BIP成为提出新功能，收集社区对问题的意见以及记录比特币设计决策的主要机制。BIP作者负责在社区内建立共识并记录不同意见。
由于BIP在版本化存储库中作为文本文件维护，因此其修订历史记录是功能提议的历史记录。
BIP有三种：
- Track BIP一个标准跟踪BIP描述了影响大多数或所有比特币实现的任何变更，例如网络协议的更改，块或交易有效性规则的更改，或影响比特币使用的应用程序的互操作性的任何更改或添加。
- Information BIP一个信息BIP描述比特币设计问题，或向比特币社区提供一般指导或信息，但不提出新功能。信息BIP不一定代表比特币社区的共识或建议，因此用户和实现者可以自由地忽略信息BIP或遵循他们的建议。
- Process BIP一个流程BIP描述了围绕比特币的流程，或者建议改变流程（或事件）。流程BIP类似于标准跟踪BIP，但适用于比特币协议本身以外的区域。他们可能会提出一个实现，但不会提到比特币的代码库; 他们经常需要社区共识; 与信息BIP不同，它们不仅仅是建议，用户通常也不能自由忽略它们。例如包括程序，指南，决策过程的变更以及比特币开发中使用的工具或环境的变更。任何meta-BIP也被视为流程BIP。
BIP流程从比特币的新想法开始。每个潜在的BIP必须有一个拥护者 - 使用下面描述的风格和格式编写BIP的人，在适当的论坛中指导讨论，并尝试围绕这个想法建立社区共识。BIP作者应首先尝试确定该想法是否具有BIP能力。发布到[email protected]邮件列表（可能还有开发和技术讨论论坛）是最好的方法。
在编写BIP之前公开征求一个想法意味着既可以节省潜在的作者和更广泛的社区时间。提出的改变比特币许多想法因各种原因已经被拒绝。首先询问比特币社区，如果一个想法是原创的，有助于防止花费太多时间花在基于先前的讨论就会被拒绝的事情上（搜索互联网并不总是这样做）。它还有助于确保该想法适用于整个社区而不仅仅是作者。仅仅因为一个想法对作者来说听起来不错并不意味着它对大多数使用比特币的地区的人都有效。小的增强或补丁通常不需要在多个项目之间进行标准化; 一些不需要一个BIP的补丁应该通过一系列的提交操作注入到相关比特币开发工作中。
一旦作者向比特币社区询问某个想法是否有任何接受机会，就应该向比特币开发邮件列表提交BIP草案。这使作者有机会充实BIP草案，使其格式正确，质量高，并解决有关该提案的其他问题。在讨论之后，该提案应该与BIP草案一起发送到比特币开发列表和BIP编辑器。该草案必须按如下所述的方式编写BIP，否则不会获得更多关注就会被退回，知道遵守正确的格式规则。
BIP作者负责收集社区对初始想法和BIP的反馈，然后再提交审核。尤其，应尽可能避免在公共邮件列表上进行长时间的开放式讨论。保持有效讨论的策略包括：为主题设置单独的SIG邮件列表，让BIP作者在早期设计阶段接受私人评论，设置维基页面或git存储库等. BIP作者应在此时自行决定。
强烈建议单个BIP包含单个关键提议或新想法。BIP越集中，它就越成功。如果有疑问，请将您的BIP分成几个注重焦点的BIP。
BIP编者分配BIP号码并更改其状态。请将所有与BIP相关的电子邮件发送至BIP编者，编者列在下面的BIP编者中。另请参阅BIP编辑职责和工作流程。BIP编者保留拒绝BIP提案的权利，如果它们显得过于集中或过于宽泛。
作者不得自行分配BIP号码，但应使用别名，如“bip-johndoe-infinitebitcoins”，其中包括作者姓名/昵称和BIP主题。
如果BIP编者批准，他将为BIP分配一个编号，将其标记为Standards Track，Informational或Process，将其标记为“Draft”，并将其添加到BIPs git存储库。BIP编者不会无理拒绝BIP。拒绝BIP状态的原因包括重复工作，无视格式规则，过于专注或过于宽泛，技术上不健全，没有提供适当的动机或解决向后兼容性，或者不符合比特币理念。要使BIP被接受，它必须符合某些最低标准。它必须是对提议的增强的清晰和完整的描述。增强必须代表一个网络改进。如果适用，拟议的实施必须是可靠的，不得过度使协议复杂化。
BIP作者可以在git存储库中根据需要更新草稿。作者也可以提交对草稿的更新作为拉取请求。
标准跟踪BIP由两部分组成，即设计文档和参考实现。在参考实现开始之前，BIP应先被审查和被接受，除非参考实现将有助于人们研究BIP。标准跟踪BIP在被视为最终Final之前必须包含一个实现 - 以代码，补丁或URL的形式。
一旦BIP被接受，就必须完成参考实现。当参考实现完成并被社区接受时，状态将更改为“最终Final”。
BIP也可以被指定为“延期Deferred”状态。当BIP没有取得进展时，BIP作者或编辑可以将BIP指定为此状态。一旦推迟BIP后，BIP编辑可以将其重新分配为草稿状态。
BIP也可以“拒绝Rejected”。也许该说的都说了，该做的都做了，这不是个好想法。记录这一事实仍然很重要。
BIP也可以被不同的BIP取代。这适用于信息BIP，其中API的版本2可以替换版本1。
BIP状态的可能路径如下：
如果某些信息和流程BIP从未打算完成，它们也可能具有“活动”状态。例如BIP 1（此BIP）。
每个BIP应包含以下部分：
- 序言 - 包含有关BIP的元数据的RFC 822样式标题，包括BIP号码，简短描述性标题（限制为最多44个字符），名称以及每个作者的联系信息等。
- 摘要 - 对正在解决的技术问题的简短（约200字）描述。
- 版权/公共域 - 每个BIP必须明确标记为放置在公共域中（请参阅此BIP作为示例）或根据开放出版许可证获得许可。
- 规范 - 技术规范应描述任何新功能的语法和语义。规范应该足够详细，以允许任何当前比特币平台（Satoshi，BitcoinJ，bitcoin-js，libbitcoin）的竞争性，可互操作的实现。
- 动机 - 对于想要改变比特币协议的BIP，动机至关重要。它应该清楚地解释为什么现有的协议规范不足以解决BIP解决的问题。没有足够动力的BIP提交可能会被彻底拒绝。
- 理由 - 理由通过描述设计的动机和制定特定设计决策的原因来充实规范。它应描述被考虑的替代设计和相关工作，例如，如何在其他语言中支持该功能。
- 理由应该提供社区内共识的证据，并讨论在讨论中提出的重要异议或关注。
- 向后兼容性 - 所有引入向后不兼容性的BIP必须包含描述这些不兼容性及其严重性的部分。BIP必须解释作者如何处理这些不兼容性。没有足够的向后兼容性的BIP提交可能会被彻底拒绝。
- 参考实现 - 参考实现必须在任何BIP被赋予状态“最终”之前完成，但不需要在BIP被接受之前完成。最好先完成规范和基本原理，然后在编写代码之前就此达成共识。
- 最终实现必须包括适用于比特币协议的测试代码和文档。
BIP应以mediawiki或markdown格式编写。
每个BIP必须以RFC 822样式标头前导码开头。标题必须按以下顺序显示。标有“*”的标题是可选的，如下所述。所有其他标头都是必需的。
BIP: <BIP number>
Title: <BIP title>
Author: <list of authors' real names and optionally, email addrs>
* Discussions-To: <email address>
Status: <Draft | Active | Accepted | Deferred | Rejected |
Withdrawn | Final | Superseded>
Type: <Standards Track | Informational | Process>
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
* Post-History: <dates of postings to bitcoin mailing list>
* Replaces: <BIP number>
* Superseded-By: <BIP number>
* Resolution: <url>
Author标题列出了BIP的所有作者/所有者的姓名和电子邮件地址。Author标头值的格式必须是
Random J. User<[email protected]>
包含电子邮件地址的写法
随机J.用户
没有给出邮件地址的写法。
如果有多个作者，则每个作者应遵循RFC 2822延续行约定。
注意：Resolution仅适用于Standards TrackBIP。它包含一个URL，该URL应指向发送有关BIP的声明的电子邮件或其他Web资源。
虽然BIP正处于私人讨论中（通常在初始草案阶段），但是一个Discussions-To指示正在讨论BIP的邮件列表或URL。没有讨论 - 如果正在与作者或比特币电子邮件邮件列表私下讨论BIP，则需要标题。
Type指定BIP的类型：Standards Track，Informational或Process。
Created记录了BIP分配号码的日期，而Post-History用于记录BIP的新版本发布到比特币邮件列表的日期。两个标题都应采用yyyy-mm-dd格式，例如2001-08-14。
BIP可能有一个Requires标头，表示此BIP所依赖的BIP号码。
BIP还可以具有Superseded-By标头，指示BIP已被稍后的文档废弃; 该值是替换当前文档的BIP的编号。较新的BIP必须有一个Replaces标头，其中包含过时的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，可以通过[email protected]联系。
BIP编辑订阅比特币开发邮件列表。所有与BIP相关的信件应发送（或CC）到[email protected]。
对于每个新BIP进入编辑后，执行以下操作：
- 阅读BIP以检查它是否准备就绪：完整程度。这些想法必须具有技术意义，即使它们似乎不太可能被接受。
- 标题应准确描述内容。
- 编辑BIP的语法（拼写，语法，句子结构等），标记（用于reST BIP），代码样式（示例应与BIP 8和7匹配）。
如果BIP尚未就绪，编辑器会将其发送回作者进行修订，并附上具体说明。
一旦BIP准备好仓库，就应该将其作为“pull request” 提交给GitHub上的bitcoin / bips存储库，在那里它可以获得进一步的反馈。
BIP编辑将：
- 在拉取请求注释中分配BIP编号（几乎总是只是下一个可用的编号，但有时它是特殊/笑话编号，如666或3141）。
- 在作者准备好时合并拉取请求（允许一些时间进行进一步的同行评审）。
- 在README.mediawiki中列出BIP
- 通过后续步骤将电子邮件发回给BIP作者（发布到bitcoin-dev邮件列表）。
BIP编辑旨在履行行政和编辑职责。BIP编辑器监视BIP的变化，并纠正我们看到的任何结构，语法，拼写或标记错误。
该文档承自Python的PEP-0001。在许多地方，文本只是被复制和修改。尽管PEP-0001文本由Barry Warsaw，Jeremy Hylton和David Goodger编写，但他们对比特币改进过程中的使用不负责任，并且不应该对比特币或BIP过程特有的技术问题被打扰。请将所有意见直接发送给BIP编辑或比特币开发邮件列表。
2015年10月10日 - 添加了有关提交流程和BIP号码分配的说明。
2016年1月1日 – 阐明BIP理念倡导的早期阶段，收集社区反馈等。
本文作者：architect.bian，欢迎收藏，转载请保留原文地址并保留版权声明！谢谢~
还没完！往下看！！！