BIP3 revisions

bip-0003.md

@@ -30,21 +30,22 @@ BIP types more clearly, and generalizes the BIP process to fit the community
 
 ### What is a BIP?
 
-BIPs are improvement proposals for Bitcoin[^capitalization]. The main topic is information and technologies that support and expand the utility of the bitcoin
+BIPs are improvement proposals for Bitcoin. 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
 the Bitcoin protocol, peer-to-peer network, and client software may be acceptable.
 
 BIPs are intended to be a means for proposing new protocol features, coordinating client standards, and
-documenting design decisions that have gone into implementations. A BIP may be submitted by anyone,
+documenting design decisions that have gone into implementations thereof.
+BIPs should cover topics that at least potentially have a need of standardization, involving multiple projects, and not merely configuration (such as default settings or per-node policies, except where the latter may overlap with standardized interactions).
+A BIP may be submitted by anyone,
 provided it is the original work of its authors and the content is of high quality, e.g. does not waste
-the community's time. No content may be generated by AI/LLMs and authors must proactively disclose
-up-front any use of AI/LLMs.
+the community's time. No content may be generated by AI/LLMs.
 
 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.
+electronic cash system for the Bitcoin currency.
 
 ### BIP Ownership
 
@@ -56,8 +57,8 @@ co-owned by the Bitcoin community.
 #### Authors and Deputies
 
 Authors may want additional help with the BIP process after writing an initial draft. In that case, they may assign
-one or more Deputies to their BIP. Deputies are stand-in owners of a BIP who were not involved in writing the
-document. They support the authors in advancing the proposal, or act as a point of contact for the BIP in the absence of the
+one or more Deputies to their BIP.
+Deputies support the authors in advancing the proposal, or act as a point of contact for the BIP in the absence of the
 authors. Deputies may perform the role of Authors for any aspect of the BIP process unless overruled by an Author.
 Deputies share ownership of the BIP at the discretion of the Authors.
 
@@ -86,7 +87,8 @@ No formal or informal decision body governs Bitcoin development or decides adopt
 
 Authors may choose to submit BIPs in MediaWiki or Markdown[^markdown] format.
 
-Each BIP must have a _Preamble_, an _Abstract_, a _Copyright_, and a _Motivation_ section. Authors should consider all issues in the
+Each BIP must have a _Preamble_, an _Abstract_, a _Motivation_, a _Specification, and a _Copyright_ section.
+Authors should consider all issues in the
 following list and address each as appropriate.
 
 * Preamble — Headers containing metadata about the BIP (see the section [BIP Header Preamble](#bip-header-preamble)
@@ -103,7 +105,7 @@ following list and address each as appropriate.
   implementers and users should deal with these incompatibilities.
 * Reference Implementation — Where applicable, a reference implementation, test vectors, and documentation must be
   finished before the BIP can be given the status "Complete". Test vectors must be provided in the BIP or
-  as auxiliary files (see [Auxiliary Files](#auxiliary-files)) under an acceptable license. The reference implementation can be provided in the BIP, as an auxiliary file, or per reference to a pull request that is expected to remain available permanently.
+  as auxiliary files (see [Auxiliary Files](#auxiliary-files)) under an acceptable license. The reference implementation can be provided in the BIP as an auxiliary file, reference to a pull request (expected to remain available permanently), a new code repository, or similar.
 * Changelog — A section to track modifications to a BIP after reaching Complete status.
 * Copyright — The BIP must be placed under an acceptable license (see [BIP Licensing](#bip-licensing) below).
 
@@ -175,7 +177,7 @@ do not need to adhere to a specific convention.
 ### BIP Types
 
 * A **Specification BIP** defines a set of technical rules describing a new feature or affecting the interoperability of implementations. The
-  distinguishing characteristic of a Specification BIP is that it can be implemented, and implementations can be compliant with
+  distinguishing characteristic of a Specification BIP is that it can be implemented, and implementations can be compatible with
   it. Specification BIPs must have a Specification section, must have a Backward Compatibility section (if incompatibilities are introduced), and can only be advanced to Complete after they contain or refer to a reference implementation and test vectors.
 * An **Informational BIP** describes a Bitcoin design issue, or provides general guidelines or other information to the
   Bitcoin community.
@@ -231,12 +233,12 @@ specification above.
 After fleshing out the proposal further and ensuring that it is of high quality and properly formatted, the authors
 should open a pull request to the [BIPs repository](https://github.com/bitcoin/bips). The document must adhere to the
 formatting requirements specified above and should be provided as a file named with a working title of the form
-"bip-title.[md|mediawiki]". The authors must not self-assign a number to their proposal.
+"bip-title.[md|mediawiki]".
+Only BIP Editors may assign BIP numbers; until one has done so, author(s) should refer to their BIP by name only (filenames should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject).
 
 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. A number may be
+ideation phase, will be assigned a number by a BIP Editor.
+A number may be
 considered assigned only after it has been publicly announced in the pull request 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
@@ -259,14 +261,16 @@ When the authors have concluded all planned work on their proposal, are confiden
 improvement, is clear, comprehensive, and is
 ready for adoption by the Bitcoin community, they may update the BIP’s status to Complete to indicate that they
 recommend adoption, implementation, or deployment of the BIP. Where applicable, the authors must ensure that any
-proposed specification is solid, not unduly complicated, and definitive. Specification BIPs must come with or refer to a working reference implementation and comprehensive test vectors before they can be moved to Complete. Subsequently, the BIP’s content should only be
+proposed specification is solid, not unduly complicated, and definitive.
+Specification BIPs must come with or refer to a working reference implementation and should include comprehensive test vectors before they can be moved to Complete.
+Subsequently, the BIP’s content should only be
 adjusted in minor details, e.g., to improve language, clarify ambiguities, backfill omissions in the specification, add
 test vectors for edge cases, or address other issues discovered as the BIP is being adopted.
 
 A Complete BIP can only move to Deployed or Closed. Any necessary changes to the specification should be minimal and
 interfere as little as possible with ongoing adoption. If a Complete BIP is found to need substantial functional
 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 compatible with the BIP means.
 
 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.
@@ -463,7 +467,7 @@ The current BIP Editors are:
 The BIP Editors subscribe to the Bitcoin Development Mailing List and watch the [BIPs
 repository](https://github.com/bitcoin/bips).
 
-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
+When either a new BIP idea or an early draft is submitted to the mailing list, BIP Editors and/or other community members should comment in regard
 to:
 
 * Novelty of the idea
@@ -481,22 +485,22 @@ repository](https://github.com/bitcoin/bips) where it may get further feedback.
 
 For each new BIP pull request that comes in, an editor checks the following:
 
-* The idea has been previously proposed by one of the authors to the Bitcoin Development Mailing List and discussed there
+* The idea has been previously proposed to the Bitcoin Development Mailing List and discussed there
 * The described idea is on-topic for the repository
 * Title accurately describes the content
 * Proposal is of general interest and/or pertains to more than one Bitcoin project/implementation
 * Document is properly formatted
 * Licensing terms are acceptable
 * Motivation, Rationale, and Backward Compatibility have been addressed
 * Specification provides sufficient detail for implementation
-* The defined Layer header must be correctly assigned for the given specification
+* The defined Type and Layer headers must be correctly assigned for the given specification
 * The BIP is ready: it is comprehensible, technically feasible and sound, and all aspects are addressed as necessary
 
 Editors do NOT evaluate whether the proposal is likely to be adopted.
 
 Then, a BIP Editor will:
 
-* Assign a BIP number and BIP type in the pull request
+* Assign a BIP number in the pull request
 * Ensure that the BIP is listed in the [README](README.mediawiki)
 * Merge the pull request when it is ready
 
@@ -522,7 +526,7 @@ mentioned in the [Changelog](#changelog) section.
 - The comment system is abolished.[^comments]
 - A BIP in Draft or Complete status may no longer be closed solely on grounds of not making progress for three years.[^rejection]
   - A BIP in Draft status may be updated to Closed status if it appears to have stopped making progress for at least a
-    year and its authors do not assert within four weeks of being contacted that they are still working on it.
+    year and its authors do not assert within four weeks of being contacted that they intend to continue working on it.
   - Complete BIPs can only be moved to Closed by its authors and may remain in Complete indefinitely.
 - A Changelog section is introduced to track significant changes to BIPs after they have reached the Complete status.
 - Process BIPs are living documents that do not ossify and may be modified indefinitely.
@@ -625,9 +629,6 @@ feedback, and helpful comments.
     has frequently led to confusion, with authors using the date of opening the pull request, the date they started
     writing their proposal, the date of number assignment (as prescribed), or various other dates. Aligning the name of
     the header and the text in the preamble template with the descriptions will reduce the confusion.
-[^capitalization]: **When is Bitcoin capitalized and when is it lowercased?**  
-    This document uses capitalized Bitcoin to refer to the system, network and abstract concept, and only uses lowercase
-    bitcoin to refer to units of the bitcoin currency.
 [^standard-track]: **Why was the Specification type introduced?**  
     The definitions of Informational and Standards Track BIPs caused some confusion in the past. Due to Informational
     BIPs being described as optional, Standards Track BIPs were sometimes misunderstood to be generally recommended.
@@ -647,7 +648,7 @@ feedback, and helpful comments.
     Standards Track BIPs is dropped.
 [^OtherImplementations]: **What is the issue with "Other Implementations" sections in BIPs?**  
     In the past, some BIPs had "Other Implementations" sections that caused frequent change requests to existing BIPs.
-    This put an onus on the BIP authors, and frequently led to lingering pull requests due to the corresponding BIPs’
+    This put a burden on the BIP authors and editors, frequently leading to lingering pull requests due to the corresponding BIPs’
     authors no longer participating in the process. Many of these alternative implementations eventually became
     unmaintained or were low-quality to begin with. Therefore, "Other Implementations" sections are heavily discouraged.
 [^complete]: **Why was the Proposed status renamed to Complete?**  
@@ -694,7 +695,7 @@ feedback, and helpful comments.
     preferred.
 [^new-BIP]: **Why should the specification of an implemented BIP no longer be changed?**  
     After a Complete or Deployed BIP has been deployed by one or more implementations, breaking changes to the
-    specification could lead to a situation where multiple "compliant" implementations fail at being interoperable,
+    specification could lead to a situation where multiple "compatible" implementations fail at being interoperable,
     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.