# BIP 0002 By [moonfunjohn](https://paragraph.com/@verashang) · 2022-04-08 --- BIP: 2 Title: BIP process, revised Author: Luke Dashjr luke+bip@dashjr.org Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0002 Status: Active Type: Process Created: 2016-02-03 License: BSD-2-Clause OPL Replaces: 1 摘要 -- 比特币改进提案 (BIP) 是一份设计文档，用于为比特币社区提供信息，描述比特币的新功能，描述比特币运作流程或运行环境。 BIP应提供新功能简明的技术规范和基本原理。 我们希望 BIP 成为提出新功能、收集社区对某个问题的意见以及记录已进入比特币的设计决策的主要机制。BIP 作者负责在社区内建立共识并记录不同意见。 因为 BIP 在版本化存储库中作为文本文件进行维护，所以它们的修订历史是功能提议的历史记录。 本BIP将提出一个更明确，更清晰的流程，代替BIP 1。 版权 -- 此 BIP 在 Open Publication License 和 BSD 2-clause 许可下获得双重许可。 BIP工作流程 ------- BIP 流程始于比特币的新想法。每个潜在的 BIP 都必须有一个拥护者(通常是作者)——使用下面描述的风格和格式编写 BIP、在适当的论坛中引导讨论并尝试围绕该想法建立社区共识的人。 BIP 拥护者（又名作者）应首先尝试确定该想法是否适用于 BIP。对特定软件的小改进或补丁通常不需要多个项目之间的标准化；这些不需要 BIP，并且应该通过将补丁提交到适用的问题跟踪器来注入到相关的项目特定开发工作流程中。一直以来，已经有许多改变比特币的想法，但由于各种原因被拒绝。 第一步应该是搜索过去的讨论，看看以前的人是否已经考虑过一个想法，如果是，那么在其进展过程中出现了哪些问题。 在调查了过去的工作之后，才决定是否将新想法发布到 \[[bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)\]。 在编写 BIP 之前公开审视一个想法是为了节省潜在作者和更广泛的社区时间。首先询问比特币社区一个想法是否是原创的，这有助于防止将太多时间花在根据之前的讨论肯定会被拒绝的事情上（搜索互联网并不总是能奏效）。它还有助于确保该想法适用于整个社区，而不仅仅是作者。仅仅因为一个想法对作者来说听起来不错并不意味着它适用于大多数使用比特币的领域的大多数人。 一旦拥护者试图向比特币社区询问一个想法是否有机会被接受，他应该将 BIP 草案提交给 \[[bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)\] 邮件列表。这使作者有机会充实 BIP 草案，确保其使用正确的格式、质量高，并解决对该提案的其他担忧。经过讨论，提案应与 BIP 草案一起发送给比特币开发人员列表和 BIP 编辑。此草稿必须以 BIP 样式编写，并以 “bip-johndoe-infinitebitcoins” 等别名命名，直到编辑为其分配了 BIP 编号（作者不得自行分配 BIP 编号），否则它将被退回。 BIP 作者负责收集社区对最初想法和 BIP 的反馈，然后再提交审核。但是，应尽可能避免在公共邮件列表上进行长时间的开放式讨论。保持讨论效率的策略包括：为该主题设置一个单独的 SIG 邮件列表，让 BIP 作者在早期设计阶段接受私人评论，设置 wiki 页面或 git 存储库等。 强烈建议单个 BIP 包含单个关键提案或新想法。 BIP 越专注，它就越容易成功。如果有疑问，请将您的 BIP 拆分为几个重点突出的 BIP。 当 BIP 草案完成后，BIP 编辑将为 BIP 分配一个编号，将其标记为Standards Track、Informal 或 Process，并将拉取请求合并到 BIP git 存储库。 BIP 编辑不会无理拒绝 BIP。 拒绝 BIP 的原因包括重复工作、无视格式化规则、过于专注或过于宽泛、技术不健全、没有提供适当的动机或解决向后兼容性问题，或者不符合比特币哲学。 要使 BIP 被接受，它必须满足某些最低标准。它必须是对提议的增强功能的清晰完整的描述。增强必须代表净改进。提议的实现（如果可以提供的话）必须是可靠的，并且不得过度复杂化协议。 BIP 作者可以根据需要在 git 存储库中更新草稿。对草稿的更新也应该由作者作为拉取请求提交。 ### 转让BIP所有权 有时有必要将 BIP 的所有权转让给新的拥护者。 一般来说，我们希望保留原作者作为转移的 BIP 的共同作者，但这取决于原作者。转让所有权的理由可能是因为原作者不再有时间或兴趣更新它或遵循 BIP 流程，或者已经脱离了“网络”（即无法访问或不回复电子邮件）。转让所有权的一个不好的理由是您不同意 BIP 的方向。我们试图围绕 BIP 建立共识，但如果您不同意此BIP，您可以随时提交竞争性 BIP。 如果您有兴趣承担 BIP 的所有权，请发送消息要求接管，并发送给原始作者和 BIP 编辑。 如果原作者没有及时回复邮件，BIP 编辑会做出单方面的决定（并不是说这样的决定是不能撤销的：）。 ### BIP编辑 当前的BIP编辑是： * Luke Dashjr ([luke\_bipeditor@dashjr.org](https://mailto:luke_bipeditor@dashjr.org)) * Kalle Alm ([karljohan-alm@garage.co.jp](https://mailto:karljohan-alm@garage.co.jp)) ### BIP 编辑的职责和工作流程 BIP 编辑会订阅比特币开发邮件列表。邮件列表外的 BIP 相关信函应发送（或抄送）给 BIP 编辑。 对于发送给编辑的每个新 BIP，请执行以下操作： * 阅读 BIP 以检查它是否准备就绪：健全且完整。这些想法必须具有技术意义，即使它们似乎不太可能被接受。 * 标题应准确描述内容。 * BIP 草案必须已发送到比特币开发邮件列表以供讨论。 * 必须解决动机和向后兼容性（如适用）。 * 必须为给定规范正确分配定义的层标头。 * BIP 必须接受许可条款。 如果 BIP 尚未准备好，编辑会将其发回给作者进行修改，并附上具体说明。 一旦 BIP 准备好用于存储库，它应该作为“拉取请求”提交到 \[[BIPs git 存储库](https://github.com/bitcoin/bips)\]，在那里它可能会获得进一步的反馈。 然后，BIP 编辑将： * 在拉取请求中分配一个 BIP 编号。 * 准备好后合并拉取请求。 * 在 \[\[README.mediawiki\]\] 中列出 BIP BIP 编辑旨在履行行政和编辑职责。 BIP 编辑会监视 BIP 更改，并根据需要更新 BIP 标头。 BIP格式和架构 -------- ### 规格 BIP 应以 mediawiki 格式编写。 每个 BIP 应具有以下部分： * 前言 -- 包含有关 BIP 元数据的标头（\[\[#BIP header preamble|见下文\]\]）。 * 摘要——对正在解决的技术问题的简短描述（约 200 字）。 * 版权- BIP 必须根据可接受的版权条款明确许可（\[\[#BIP 许可|见下文\]\]）。 * 规范——技术规范应该描述任何新特性的语法和语义。该规范应该足够详细，以允许当前任何比特币平台的竞争性、互操作性实现。 * 动机——动机对于想要改变比特币协议的 BIP 来说至关重要。它应该清楚地解释为什么现有协议不足以解决 BIP 解决的问题。 * 基本原理——基本原理通过描述设计的动机以及做出特定设计决策的原因来充实规范。它应该描述所考虑的替代设计和相关工作。应提供社区内达成共识的证据，并描述在讨论期间提出的重要反对意见或担忧。 * 向后兼容性——所有引入向后不兼容性的 BIP 必须包含描述这些不兼容性及其严重性的部分。 BIP 必须解释作者建议如何处理这些不兼容性。 * 参考实现——参考实现必须在任何 BIP 被赋予“最终”状态之前完成，但在 BIP 被接受之前不需要完成。最好先完成规范和原理，并在编写代码之前达成共识。最终实现必须包括适用于比特币协议的测试代码和文档。 ### BIP 前言 每个 BIP 必须以 RFC 822 样式的标头序言开头。 标题必须按以下顺序出现。 标有“\*”的标题是可选的，其他标题都是必需的。 
      BIP: 
    * Layer: 
      Title: 
      Author: <作者（名字和邮件地址）列表>
    * Discussions-To: <邮件地址>
    * Comments-Summary: <摘要>
      Comments-URI: 
      Status: 
      Type: 
      Created: <创建日期, 格式是 ISO 8601 (yyyy-mm-dd)>
      License: <批准许可>
    * License-Code: <批准许可编号>
    * Post-History: 
    * Requires: 
    * Replaces: 
    * Superseded-By:
Layer 标头（仅适用于标准跟踪 BIP）记录 BIP 适用于比特币的哪一层。 有关各种 BIP 层的定义，请参见 \[BIP 123\]。本 BIP 的激活意味着 BIP 123 的激活。 作者标头列出了 BIP 的所有作者/所有者的姓名和电子邮件地址。 作者标头的格式必须为 Random J. User 如果有多个作者，则每个作者都应该按照 RFC 2822 续行约定在单独的行上。 当 BIP 处于私人讨论中时（通常在最初的草稿阶段）， Discussions-To 标头将指示正在讨论 BIP 的邮件列表或 URL。如果 BIP 正在与作者私下讨论，或者在比特币电子邮件邮件列表中，则不需要 Discussions-To 标头。 Type 标头指定 BIP 的类型：Standards Track、Informal 或 Process。 Created 标头记录了 BIP 被分配编号的日期，而 Post-History 用于记录 BIP 的新版本何时发布到比特币邮件列表。 日期应采用 yyyy-mm-dd 格式，例如2001-08-14。 Post-History 允许作为邮件列表存档中特定线程的链接。 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，但适用于比特币协议本身以外的领域。他们可能会提出一个实施方案，但不会针对比特币的代码库；它们通常需要社区共识；与信息 BIP 不同，它们不仅仅是建议，而且用户通常不能随意忽略它们。示例包括程序、指南、决策过程的更改以及比特币开发中使用的工具或运行环境的更改。任何元 BIP 也被视为流程 BIP。 BIP状态字段 ------- ### 规格 BIP状态的典型路径如下： ![BIP状态路径](https://storage.googleapis.com/papyrus_images/b8fe060d5f9b9e8e8927eadc91cc980d6ad556ec573b60307eb04b4bc873ce6b.png) BIP状态路径 BIP 的拥护者可以自行决定在草案、延期或撤回之间更改状态。 当 BIP 没有进展时，BIP 编辑也可以将状态更改为延期。 只有当作者认为 BIP 已完成，并且有一个正在进行中的实现（如适用），并且社区有计划将其推进到最终状态时，BIP 才能将状态从草稿（或已拒绝）更改为已提议。 如果 BIP 在三年内没有取得进展，则任何人都可以要求将其从 Draft 或 Proposed 状态更改为 Rejected 状态。如果拥护者提供了有意义地解决公众对提案的批评的修订，则此类 BIP 可能会更改为草稿状态，或者如果它符合上一段中所述的要求的标准，则可以将其更改为建议状态。 仅当出现反映实际采用的特定标准时，提议的 BIP 才能进入最终阶段。这对于每个 BIP 都是不同的，具体取决于其提议的更改的性质，这将在下面进行扩展。对此状态变化的评估应该是客观可验证的，可在开发邮件列表中进行讨论。 当最终 BIP 不再相关时，其状态可能会更改为已替换或已过时（相当于已替换）。这种变化也必须是客观可验证，可讨论的。 当流程 BIP 在邮件列表上达成大致共识时，它可能会将状态从草稿更改为激活。如果这样的提议已经在开发邮件列表上公开讨论至少一个月，并且没有人对此提出任何未解决的、经证实的反对意见，那么可以认为这个提议具有初步的共识。阻碍性的反对意见需要给出明确的理由，得到充分解决，得到大多数社区成员的共识，它们才能被忽略。 ### 进入最终阶段 软分叉 BIP 必须通过区块链投票（例如，使用 BIP 9）并获得多数矿工的支持才能进入最终阶段。此外，如果比特币经济体似乎愿意进行“信心不足的”硬分叉（例如改变工作量证明算法），那么只要这样的硬分叉可能，软分叉就不会成为 Final获得多数支持，或最多三个月。软分叉 BIP 也可能对其采用设置额外的要求。由于矿工动态可能发生变化，特别是考虑到委托投票（矿池），强烈建议 BIP 本身要求 95% 左右的绝对多数投票，除非给出较低阈值的理由。 硬分叉 BIP 需要整个比特币经济体采用，特别是包括那些出售理想商品和服务以换取比特币支付的人，以及希望以不同方式使用或将使用比特币（包括以其他货币出售）的比特币持有者这种硬分叉的事件。必须通过在实践中实际使用硬分叉来表示采用（即，不仅仅是表达公众支持，尽管这是在采用 BIP 之前建立协议的一个很好的步骤）。这种经济采用不能仅仅由绝大多数人来建立，除非从字面上强迫少数人接受硬分叉（无论这是否可行，都超出了本文的范围）。 节点服务 BIP 在一个月内被至少 1% 的公共监听节点采用。 API/RPC 和应用层 BIP 必须被至少两个独立且兼容的软件应用程序实现。 鼓励软件作者发布其软件支持的 BIP 的摘要，以帮助验证状态更改。在编写此 BIP 时，可以在 \[[比特币核心的 doc/bips.md 文件](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md)\] 以及\[[安卓钱包/README.specs.md 文件的比特币钱包](https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/wallet/README.specs.md)\]。 这些标准虽然被认为是观察 BIP 实际实施的客观方法，但不能用作反对或拒绝 BIP 的理由。如果 BIP 不符合此处概述的标准，但实际上被采用，它仍应更新为最终状态。 ### 背后的理由 为什么BIP 2是必要的？ * BIP 1 为 BIP 的状态字段定义了一个模棱两可的标准，导致许多具有重要实际用途的 BIP 被保留为”草案”，或者”建议”状态的时间超过了适当的时间。本该提案通过提供客观标准来判断 BIP 的进展，旨在帮助 BIP 保持状态准确和最新。 整个比特币经济圈为什么要被定义成销售商品/服务的人和比特币持有者？ * 要使比特币作为一种货币发挥作用，它必须被接受为付款方式。如果您无法获得任何东西来换取比特币，那么比特币就没有价值。如果每个接受此类支付的人都需要特定的共识规则，那么“比特币”实际上就是由那套规则定义的——今天已经是这样了。如果这些共识规则预计会扩大（如硬分叉），那么这些商家需要接受根据新规则进行的付款，否则他们将拒绝“比特币”。比特币持有人的相关程度在于他们选择了希望与他们一起使用比特币的商家，并且也可以作为一个整体决定在一套共识规则或另一套共识规则下出售，从而使市场充斥着比特币并导致价格暴跌。 为什么 不包含在经济中？ 在某种程度上，某些实体也可能参与提供商品和/或服务以换取比特币，因此以这种身份（但不是他们作为 的身份）参与经济。 _矿工不包括在经济中，因为他们只是_依靠其他人出售/花费他们原本毫无价值的开采产品。因此，他们在决定共识规则时必须接受其他人的指导。 交易所不包括在经济中，因为它们只是提供连接商户和希望交易的用户的服务。即使所有交易所都背离比特币，这些商家和用户始终可以直接交易和/或建立自己的交易所。 开发人员不包括在经济中，因为他们只是编写代码，由其他人决定是否使用该代码。 但他们正在做一些重要的事情，并且在比特币上投入了大量资金！他们不应该被包括在如此重要的决定中吗？ 本 BIP 并非旨在解决“应该”作为决策基础的内容。这样的声明，无论其理由多么完美，如果没有某种方式强迫他人使用它，都是徒劳的。 BIP 流程并非旨在成为一种强有力的比特币“治理”，而只是提供一个协作存储库，用于提出和提供人们可能自愿采用或不采用的标准信息。它只能希望通过努力反映_事物实际上是如何_的现实，而不是_它们应该如何_来实现“状态”领域的准确性。 如果单个商家希望阻止硬分叉怎么办？ 此 BIP 仅涉及 BIP 状态字段的进展，而不涉及硬分叉（或任何其他更改）本身的部署。 无论如何，一家商店不能在真空中运营：如果他们确实是孤身一人，他们很快就会发现自己不再出售商品或者服务以换取比特币支付，因为没有其他人愿意使用以前的区块链来支付他们的费用。如果他们不再销售，他们将不再符合此处允许他们否决的标准。 少数商家（可能只有两个）互相销售产品怎么样？ 在这种情况下，之前的比特币似乎还活着并且正在工作，而硬分叉失败了。如何解决这种分裂超出了本 BIP 的范围。 经济协议如何否决软分叉？ 矿工组由动态成员多方签名（比特币为工作量证明算法）的共识规则确定，可以通过硬分叉进行修改。因此，如果修改该组所需的相同条件与软分叉相反，那么支持软分叉的矿工多数实际上是无效的，因为经济可以决定用另一组潜在矿工代替他们不支持软分叉。 如果经济体在三个多月后决定从有争议的软分叉中硬分叉，会发生什么？ 在这种情况下，有争议的软分叉从 Final 状态变为 Replaced 状态，以反映硬分叉取代先前（最终）软分叉的性质。 采用节点服务提案所需的监听节点的理想百分比是多少？ 这个是未知的，在这个时候设置得比较随意。对于随机选择的对等点，至少有一个其他对等点实施扩展，需要 13% 或更多，但节点可以继续扫描网络以寻找这样的对等点，也许会取得一些合理的成功。此外，存在服务位以帮助预先识别。 为什么至少有两个软件项目需要在它们成为最终版本之前发布 API/RPC 和应用层 BIP 的实现？ 如果规范只有一个实现，则没有其他程序可以使用或需要标准接口。 即使只有两个项目而不是更多，它们之间也存在一些标准的协调。 如果提议的 BIP 仅对单个特定项目有意义怎么办？ BIP 流程用于独立项目之间的标准化。如果某件事只影响一个项目，则应该通过该项目自己的内部流程来完成，并且从一开始就不要将其作为 BIP 提出。 BIP 评论 规格 每个 BIP 都应在其序言中链接到公共 wiki 页面，并带有该页面上评论的摘要。认为自己合格的 BIP 审阅者应在此 wiki 页面上发表自己的评论。评论页面通常仅用于发布已完成 BIP 的最终评论。如果 BIP 尚未完成，审查者应改为在适用的开发邮件列表线程上发布，以允许 BIP 作者解决审查指出的任何问题或问题。 一些 BIP 在完成之前会在开发社区之外获得曝光，而其他 BIP 可能根本无法完成。为避免在此期间关键 BIP 评论可能被忽视的情况，评论者可以选择在评论页面上发布他们的评论，前提是他们首先将其发布到邮件列表并计划稍后删除或修改它（如适用）基于完成的版本。此类修订应通过编辑先前的审查并更新时间戳来进行。如果在完整版本之前所做的评论不再适用并且没有及时更新（例如，在一个月内），则可能会删除它们。 页面必须以完整的 BIP 编号命名（例如，“BIP 0001”）并放置在“Comments”命名空间中。 例如，BIP 1 的链接将是 [https://github.com/bitcoin/bips/wiki/Comments:BIP-0001。](https://github.com/bitcoin/bips/wiki/Comments:BIP-0001%E3%80%82) 发布到此 wiki 的评论应使用以下格式： <您的意见> --<您的姓名>，<发布日期，如 YYYY-MM-DD> 除了 BIP wiki 之外，BIP 还可以选择列出第二个 BIP 评论论坛。 在这种情况下，第二个论坛的 URI 应该列在主要 wiki 的 URI 下方。 一段时间后，BIP 本身可能会更新为评论的摘要。可以从以下内容中选择摘要，但本 BIP 并不打算涵盖所有可能的细微差别，并且可以根据需要使用其他摘要： 暂时没有评论。 一致推荐实施 一致反对实施 主要推荐实施，但有些不鼓励 主要不鼓励实施，有一些建议 例如，BIP 1 的序言可能会更新为包括以下行： 评论-总结：还没有评论。 评论-URI：https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 https://some-other-wiki.org/BIP\_1\_Comments 这些字段必须跟在 BIP 1 中定义的“Discussions-To”标头之后（如果该标头不存在，它应该跟在它出现的位置；通常它紧接在 Status 标头之上）。 为避免疑问：评论和状态是判断 BIP 的无关指标，两者都不应该直接影响另一个。 背后的理由 BIP 评论的目的是什么？ 尽管普遍认为不建议采用各种 BIP（“最终”状态所需的标准）。目前有些人认为 BIP 是一个“好主意”，因为它们被分配了一个 BIP 编号。由于提交新 BIP 的准入门槛低，似乎建议审阅者以一种公众可以接受的方式表达他们对它们的意见，而无需审阅整个开发讨论。 BIP 评论是否会被审查或仅限于特定参与者/“专家”？ 参与者应自由地避免在其知识或专业领域之外发表评论。但是，评论不应受到审查，参与应向公众开放。 BIP 许可 规格 具有以下许可证的新 BIP 可能会被接受。每个新的 BIP 必须在其序言中确定至少一个可接受的许可证。序言中的 License 标头必须放在 Created 标头之后。每个许可证必须通过下面给出的各自缩写来引用。 例如，序言可能包含以下许可标头： 许可证：BSD-2-Clause GNU-All-Permissive 在这种情况下，BIP 文本在 OSI 批准的 BSD 2-clause 许可和 GNU All-Permissive License 下获得完全许可，并且任何人都可以修改和重新分发文本，只要他们遵守 _either_ 许可的条款.换句话说，许可证列表是一个“OR 选择”，而不是“AND Also”要求。 也可以以不同于 BIP 文本的方式许可源代码。可选的 License-Code 标头放置在 License 标头之后。同样，每个许可证必须通过下面给出的各自缩写来引用。 例如，指定可选 License-Code 标头的序言可能如下所示： 许可证：BSD-2-Clause GNU-All-Permissive 许可证代码：GPL-2.0+ 在这种情况下，BIP 中的代码在 BSD 或 All-Permissive 许可证下不可用，而仅在 GNU 通用公共许可证 (GPL) 版本 2 或更新版本的条款下可用。 如果代码在 _only_ 版本 2 下可用，则应从许可证缩写中删除“+”符号。 对于更高版本（例如，GPL 3.0），您将增加版本号（并根据意图保留或删除“+”）。 License-Code: GPL-2.0 # 这是指 GPL v2.0 \*only\*，不接受更高的许可证版本。 许可证代码：GPL-2.0+ # 这是指 GPL v2.0 \*或更高版本\*。 License-Code: GPL-3.0 # 这是指 GPL v3.0 \*only\*，不接受更高的许可证版本。 许可证代码：GPL-3.0+ # 这是指 GPL v3.0 \*或更高版本\*。 如果文本或代码的许可过于复杂而无法用简单的替代列表来表达，则应将列表替换为单个术语“复杂”。在所有情况下，必须在 BIP 的版权部分提供许可条款的详细信息。 BIP 不需要_独家_根据批准的条款获得许可，也可以根据不可接受的许可_除_至少一个可接受的许可来获得许可。 在这种情况下，只有可接受的许可证应该列在许可证和许可证代码标题中。 推荐的许可证 BSD-2-Clause：\[[OSI-approved BSD 2-clause license](https://opensource.org/licenses/BSD-2-Clause)\] BSD-3-Clause：\[[OSI-approved BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause)\] CC0-1.0：\[[Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/Creative)\] GNU-All-Permissive：\[[GNU All-Permissive License](http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html)\] 此外，建议 BIP 中包含的文字代码在与其修改的项目相同的许可条款下进行双重许可。 例如，理想情况下，用于比特币核心的文字代码将根据 MIT 许可条款以及上述之一与 BIP 文本的其余部分获得双重许可。 不推荐，但是能接受的许可证 Apache-2.0：\[[Apache 许可证，2.0 版](http://www.apache.org/licenses/LICENSE-2.0)\] BSL-1.0：\[[Boost 软件许可证，版本 1.0](http://www.boost.org/LICENSE_1_0.txt)\] CC-BY-4.0：\[[Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/Creative)\] CC-BY-SA-4.0：\[[Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/Creative)\] 麻省理工学院：\[[Expat/MIT/X11 许可证](https://opensource.org/licenses/MIT)\] AGPL-3.0+：\[[GNU Affero 通用公共许可证 (AGPL)，版本 3 或更新](http://www.gnu.org/licenses/agpl-3.0.en.html)\] FDL-1.3：\[[GNU 自由文档许可证，版本 1.3](http://www.gnu.org/licenses/fdl-1.3.en.html)\] GPL-2.0+：\[[GNU 通用公共许可证 (GPL)，版本 2 或更新](http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)\] LGPL-2.1+：\[[GNU Lesser General Public License (LGPL)，2.1 版或更新](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html)\] 不能接受的许可证 上述列表中未明确包含的所有许可证都不是比特币改进提案的可接受条款，除非后来的 BIP 扩展了这一条款以添加它们。 但是，在接受此 BIP 之前的 BIP 在其他条款下是允许的，并且在未授予其他许可时应使用这些缩写： OPL：\[[http://opencontent.org/openpub/](http://opencontent.org/openpub/) 开放出版许可证，1.0 版\] PD：发布到公共领域 背后的理由 BIP 1 允许开放出版许可证或发布到公共领域；这还不够吗？ OPL 通常被认为是过时的，而不是适合新出版物的许可证。 许多人不熟悉 OPL 条款，可能只是更喜欢使用公共领域而不是不确定条款下的许可。 OPL 许可条款允许作者阻止出版和衍生作品，这被广泛认为不适合比特币标准。 公共领域并未被普遍认为是合法行为，因此不可取。 为什么包含软件许可证？ 一些 BIP，尤其是共识层，可能在 BIP 本身中包含文字代码，根据 BIP 的确切许可条款可能不可用。 尽管如此，并非所有软件许可都可用于 BIP 中包含的内容。 为什么新 BIP 不再接受公共领域？ 在某些司法管辖区，公共领域不被视为合法的法律行为，因此 BIP 仅受版权保护，根本不允许再分发或修改。 与BIP 1不同之处 完全重新选择可接受的许可证，允许各种开放许可证，同时禁止有问题的旧选择。 Accepted Status 已重命名为 Proposed。 在 BIP 进入提议状态之前，现在需要实现（如果适用）。 BIP 评论是新引入的。 添加了许可证序言标题。 层标头包含在 BIP 123 中。 bip-XXXX 子目录中允许使用非图像辅助文件。 作者现在需要电子邮件地址。 Post-History 标题可以作为链接而不是简单的日期提供。 BIP 不再允许使用 Markdown 格式。 Resolution 标头已被删除，因为它不适用于无权做出最终决定的去中心化系统。 另参照 \* \[\[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines\]\] \* \[\[bip-0123.mediawiki|BIP 123: BIP Classification\]\] \* \[https://tools.ietf.org/html/rfc7282 RFC 7282: On Consensus and Humming in the IETF\] --- *Originally published on [moonfunjohn](https://paragraph.com/@verashang/bip-0002)*