bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-08-18 13:26:23 +00:00
Code Issues Releases Wiki Activity

bip3: Fix minor phrasing and structure issues

Browse Source
This commit is contained in:
Murch 2025-06-20 15:56:58 -07:00
parent 1889614e54
commit 2c57d8aee6
No known key found for this signature in database
GPG Key ID: 7BA035CA5B901713
1 changed files with 32 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

63
bip-0003.md
View File

@ -24,13 +24,13 @@ address the evolving needs of the BIP process.
BIP 2 was written in 2016. BIP 2 was written in 2016.
This BIP revisits aspects of the BIP 2 process 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 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 ## Fundamentals
### What is a BIP? ### 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. 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., 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 [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 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. 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 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. 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 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 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 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 #### 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 * 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. 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 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 ## Workflow
@ -220,7 +220,7 @@ overall proposal.
### Progression through BIP Statuses ### 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. specification above.
#### Draft #### 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 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 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 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 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 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 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. to refer to it by a number.
Proposals are also not ready for number assignment if they duplicate efforts, disregard formatting rules, are too 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 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 proposal may be improved to progress toward readiness. Pull requests that are proposing off-topic ideas or
have stopped making progress may be closed. 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 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 continue to update the proposal as necessary. Updates to merged documents by the authors should also be submitted as
pull requests. 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. 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. 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. Deployed.
Complete is the final status for most successful Informational BIPs. Complete is the final status for most successful Informational BIPs.
#### Deployed #### Deployed
A settled[^settled] BIP may be advanced to Deployed upon request by any community member with evidence[^evidence] that the idea A Complete BIP should only be moved to Deployed once it is settled: after its approach has solidified, its
described in the BIP is in active use. Convincing evidence includes for example: an established project having deployed support 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 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. 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 Once Deployed, the BIP is considered final.
separate BIP.[^new-BIP] 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 ##### 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 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 it has been open to discussion on the mailing list for at least proposal is said to have rough consensus if its advancement 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 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 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 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] rough consensus per the same criteria.[^living-documents]
@ -298,8 +302,8 @@ Transitions involving the Closed state are:
##### Draft ↦ Closed ##### 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 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 progress, sees accumulated feedback unaddressed, or otherwise appears stalled for a year, anyone may propose the BIP
to Closed unless the authors assert that they intend to continue work within four weeks of being contacted. 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 ##### 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 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 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). [Authors or Deputies](#authors-and-deputies) (which may be amended should the original authors make a delayed reappearance).
## BIP Licensing ## BIP Licensing
@ -441,7 +445,7 @@ In all cases, details of the licensing terms must be provided in the Copyright s
#### Not Acceptable Licenses #### Not Acceptable Licenses
All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal. 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: when no other license is granted:
* PD: Released into the public domain * PD: Released into the public domain
@ -449,7 +453,7 @@ when no other license is granted:
## BIP Editors ## BIP Editors
The current BIP editors are: The current BIP Editors are:
* Bryan Bishop ([kanzure@gmail.com](mailto:kanzure@gmail.com)) * Bryan Bishop ([kanzure@gmail.com](mailto:kanzure@gmail.com))
* Jon Atack ([jon@atack.com](mailto:jon@atack.com)) * Jon Atack ([jon@atack.com](mailto:jon@atack.com))
@ -460,10 +464,10 @@ The current BIP editors are:
### BIP Editor Responsibilities and Workflow ### 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). 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: to:
* Novelty of the idea * 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. 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 * Assign a BIP number and BIP type in the pull request
* Ensure that the BIP is listed in the [README](README.mediawiki) * Ensure that the BIP is listed in the [README](README.mediawiki)
* Merge the pull request when it is ready * 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. 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 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 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. 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 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 Complete BIPs should be avoided, but Deployed BIPs should never be subject to breaking changes to their
specification. 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?** [^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 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 raised that making announcements to the Bitcoin Developer Mailing List would introduce unnecessary noise, our