From 2c57d8aee6ba6a4568d0f5c527241b6664f16191 Mon Sep 17 00:00:00 2001 From: Murch Date: Fri, 20 Jun 2025 15:56:58 -0700 Subject: [PATCH] bip3: Fix minor phrasing and structure issues --- bip-0003.md | 63 +++++++++++++++++++++++++++-------------------------- 1 file changed, 32 insertions(+), 31 deletions(-) diff --git a/bip-0003.md b/bip-0003.md index 1624e50e..61e9cf05 100644 --- a/bip-0003.md +++ b/bip-0003.md @@ -24,13 +24,13 @@ address the evolving needs of the BIP process. BIP 2 was written in 2016. This BIP revisits aspects of the BIP 2 process that did not achieve broad adoption, reduces the judgment calls assigned to the BIP Editor role, delineates the -BIP Types more clearly, and generalizes the BIP process to meet the community’s use of the repository. +BIP types more clearly, and generalizes the BIP process to fit the community’s use of the repository. ## Fundamentals ### What is a BIP? -BIPs cover the range of interests of the Bitcoin[^capitalization] community. The main topic is information and technologies that support and expand the utility of the bitcoin +BIPs are improvement proposals for Bitcoin[^capitalization]. The main topic is information and technologies that support and expand the utility of the bitcoin currency. Most BIPs provide a concise, self-contained, technical description of one new concept, feature, or standard. Some BIPs describe processes, implementation guidelines, best practices, incident reports (e.g., [BIP 50](bip-0050.mediawiki)), or other information relevant to the Bitcoin community. However, any topics related to @@ -39,7 +39,7 @@ the Bitcoin protocol, peer-to-peer network, and client software may be acceptabl BIPs are intended to be a means for proposing new protocol features, coordinating client standards, and documenting design decisions that have gone into implementations. BIPs may be submitted by anyone. -The scope of the BIP +The scope of the BIPs repository is limited to BIPs that do not oppose the fundamental principle that Bitcoin constitutes a peer-to-peer electronic cash system for the bitcoin currency. @@ -48,7 +48,7 @@ electronic cash system for the bitcoin currency. Each BIP is primarily owned by its authors and represents the authors’ opinion or recommendation. The authors are expected to foster discussion, address feedback and dissenting opinions, and, if applicable, advance the adoption of their proposal within the Bitcoin community. As a BIP progresses through the workflow, it becomes increasingly - co-owned by the Bitcoin community. +co-owned by the Bitcoin community. #### Authors and Deputies @@ -181,7 +181,7 @@ do not need to adhere to a specific convention. * A **Process BIP** describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Specification BIPs, but apply to topics other than the Bitcoin protocol and Bitcoin implementations. They often require community consensus and are typically binding for the corresponding process. Examples include - procedures, guidelines, and changes to decision-making processes such as the BIP Process. + procedures, guidelines, and changes to decision-making processes such as the BIP process. ## Workflow @@ -220,7 +220,7 @@ overall proposal. ### Progression through BIP Statuses -The following sections refer to BIP Status Field values. The BIP Status Field is defined in the Header Preamble +The following sections refer to BIP Status field values. The BIP Status field is defined in the Header Preamble specification above. #### Draft @@ -233,18 +233,18 @@ formatting requirements specified above and should be provided as a file named w BIPs that (1) adhere to the formatting requirements, (2) are on-topic, and (3) have materially progressed beyond the ideation phase, e.g., by generating substantial public discussion and commentary from diverse contributors, by independent Bitcoin projects working on adopting the proposal, or by the authors working for an extended period toward -improving the proposal based on community feedback, will be assigned a number by a BIP editor. The BIP editors should -delay number assignment when they perceive a proposal being met with lack of interest: number assignment facilitates the +improving the proposal based on community feedback, will be assigned a number by a BIP Editor. The BIP Editors should +not assign a number when they perceive a proposal being met with lack of interest: number assignment facilitates the distributed discussion of ideas, but before a proposal garners some interest in the Bitcoin community, there is no need to refer to it by a number. Proposals are also not ready for number assignment if they duplicate efforts, disregard formatting rules, are too unfocused or too broad, fail to provide proper motivation, fail to address backward compatibility where necessary, or -fail to specify the feature clearly and comprehensively. Reviewers and BIP editors should provide guidance on how the +fail to specify the feature clearly and comprehensively. Reviewers and BIP Editors should provide guidance on how the proposal may be improved to progress toward readiness. Pull requests that are proposing off-topic ideas or have stopped making progress may be closed. -When the proposal is ready and has been assigned a number, a BIP editor will merge it into the BIPs repository. After the +When the proposal is ready and has been assigned a number, a BIP Editor will merge it into the BIPs repository. After the BIP has been merged to the repository, its main focus should no longer shift significantly, even while the authors may continue to update the proposal as necessary. Updates to merged documents by the authors should also be submitted as pull requests. @@ -264,25 +264,29 @@ interfere as little as possible with ongoing adoption. If a Complete BIP is foun changes, it may be preferable to move it to Closed[^new-BIP], and to start a new BIP with the changes instead. Otherwise, it could cause confusion as to what being compliant with the BIP means. -A BIP may remain in the Complete status indefinitely unless its authors decide to move it to Closed or it is advanced to +A BIP may remain in the Complete status indefinitely unless its authors or deputies decide to move it to Closed or it is advanced to Deployed. Complete is the final status for most successful Informational BIPs. #### Deployed -A settled[^settled] BIP may be advanced to Deployed upon request by any community member with evidence[^evidence] that the idea -described in the BIP is in active use. Convincing evidence includes for example: an established project having deployed support +A Complete BIP should only be moved to Deployed once it is settled: after its approach has solidified, its +Specification has been put through its paces, feedback from early adopters has been processed, and amendments to the BIP have stopped. +Then, a BIP may be advanced to Deployed upon request by any community member with evidence[^evidence] that +the BIP is in active use. Convincing evidence includes for example: an established project having deployed support for the BIP in mainnet software releases, a soft fork proposal’s activation criteria having been met on the network, or rough consensus for the BIP having been demonstrated. -At that point, the BIP should be considered final and any breaking changes to the BIP should be proposed as a new -separate BIP.[^new-BIP] +Once Deployed, the BIP is considered final. +Any modifications to the BIP beyond bug fixes, other minor amendments, additions to the test vectors, or editorial +changes should be avoided. +Any breaking changes to the BIP’s Specification should be proposed as a new separate BIP.[^new-BIP] ##### Process BIPs -A Process BIP may change status from Complete to Deployed when it achieves rough consensus on the Bitcoin Development Mailing List. Such a -proposal is said to have rough consensus if it has been open to discussion on the mailing list for at least -one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections +A Process BIP may change status from Complete to Deployed when it achieves rough consensus on the Bitcoin Development Mailing List. A +proposal is said to have rough consensus if its advancement has been open to discussion on the mailing list for at least +one month, the discussion achieved meaningful engagement, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. Deployed Process BIPs may be modified indefinitely as long as a proposed modification has rough consensus per the same criteria.[^living-documents] @@ -298,8 +302,8 @@ Transitions involving the Closed state are: ##### Draft ↦ Closed BIP authors may decide on their own to change their BIP’s status from Draft to Closed. If a Draft BIP stops making -progress, sees accumulated feedback unaddressed, or otherwise appears stalled for a year, the community may move the BIP -to Closed unless the authors assert that they intend to continue work within four weeks of being contacted. +progress, sees accumulated feedback unaddressed, or otherwise appears stalled for a year, anyone may propose the BIP +status be updated to Closed. The BIP is then updated to Closed unless the authors assert that they intend to continue work within four weeks of being contacted. ##### Complete ↦ Closed @@ -374,7 +378,7 @@ competing BIP. If someone is interested in assuming ownership of a BIP, they should send an email asking to take over, addressed to the original authors, the BIP Editors, and the Bitcoin Development Mailing List[^bip-announcements-to-list]. If the authors are unreachable or do not respond in a timely -manner (e.g., four weeks), the BIP editors will make a unilateral decision whether to appoint the applicants as +manner (e.g., four weeks), the BIP Editors will make a unilateral decision whether to appoint the applicants as [Authors or Deputies](#authors-and-deputies) (which may be amended should the original authors make a delayed reappearance). ## BIP Licensing @@ -441,7 +445,7 @@ In all cases, details of the licensing terms must be provided in the Copyright s #### Not Acceptable Licenses All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal. -However, BIPs predating the acceptance of this BIP were allowed under other terms, and should use these abbreviations +However, BIPs predating this proposal were allowed under other terms, and should use these abbreviations when no other license is granted: * PD: Released into the public domain @@ -449,7 +453,7 @@ when no other license is granted: ## BIP Editors -The current BIP editors are: +The current BIP Editors are: * Bryan Bishop ([kanzure@gmail.com](mailto:kanzure@gmail.com)) * Jon Atack ([jon@atack.com](mailto:jon@atack.com)) @@ -460,10 +464,10 @@ The current BIP editors are: ### BIP Editor Responsibilities and Workflow -The BIP editors subscribe to the Bitcoin Development Mailing List and watch the [BIPs +The BIP Editors subscribe to the Bitcoin Development Mailing List and watch the [BIPs repository](https://github.com/bitcoin/bips). -When a new BIP idea is submitted to the mailing list, BIP editors and other community members should comment in regard +When either a new BIP idea or an early draft is submitted to the mailing list, BIP Editors and other community members should comment in regard to: * Novelty of the idea @@ -494,16 +498,16 @@ For each new BIP pull request that comes in, an editor checks the following: Editors do NOT evaluate whether the proposal is likely to be adopted. -Then, a BIP editor will: +Then, a BIP Editor will: * Assign a BIP number and BIP type in the pull request * Ensure that the BIP is listed in the [README](README.mediawiki) * Merge the pull request when it is ready -The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP +The BIP Editors are intended to fulfill administrative and editorial responsibilities. The BIP Editors monitor BIP changes, and update BIP headers as appropriate. -BIP editors may also, at their option, unilaterally make and merge strictly editorial changes to BIPs, such as +BIP Editors may also, at their option, unilaterally make and merge strictly editorial changes to BIPs, such as correcting misspellings, mending grammar mistakes, fixing broken links, etc. as long as they do not change the meaning or conflict with the original intent of the authors. Such a change must be recorded in the Changelog if it’s noteworthy per the criteria mentioned in the [Changelog](#changelog) section. @@ -678,9 +682,6 @@ feedback, and helpful comments. because they implemented different versions of the same BIP. Therefore, even changes to the specification of Complete BIPs should be avoided, but Deployed BIPs should never be subject to breaking changes to their specification. -[^settled]: **What is meant by a BIP being settled?** - Since Deployed BIPs should not be changed, a Complete BIP should only be moved to Deployed after its Specification - has been put through its paces and changes to the BIP have stopped. [^bip-announcements-to-list]: **Why are some BIP status changes announced to the mailing list?** The BIPs repository does not and cannot track who might be interested in or has deployed a BIP. While concerns were raised that making announcements to the Bitcoin Developer Mailing List would introduce unnecessary noise, our