Merge branch 'master' into bip93-fix-threshold

Author: BenWestgate

bip-0003.md

@@ -30,21 +30,19 @@ 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,
-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.
+documenting design decisions that have gone into implementations. BIPs may be submitted by anyone, provided the
+content is of high quality, e.g., does not waste the community’s time.
 
 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
 
@@ -103,7 +101,9 @@ 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, or per linking another code reference that is expected to remain
+  available permanently such as a pull request, a dedicated branch, a new 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).
 
@@ -157,7 +157,7 @@ appear in the following order. Headers marked with "\*" are optional. All other
   discussion threads on other platforms. Entries take the format "yyyy-mm-dd: URL", e.g., `2009-01-09:
   https://www.mail-archive.com/[email protected]/msg10142.html`, using the date and URL of the start of the
   conversation. Multiple discussions should be listed on separate lines.
-* Version — The current version number of this BIP. See the [Changelog](#changelog) section below.
+* Version — The current version number of this BIP. See the [Changelog](#changelog-section-and-version-header) section below.
 * Requires — A list of existing BIPs the new proposal depends on. If multiple BIPs
   are required, they should be listed in one line separated by a comma and space (e.g., "1, 2").
 * Replaces[^proposes-to-replace] — BIP authors may put the numbers of one or more prior BIPs in the Replaces header to recommend that their
@@ -231,7 +231,8 @@ 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, authors should refer to their
+BIP by name only.
 
 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
@@ -331,7 +332,7 @@ if the prior attempt had been assigned a number, the new BIP will generally be a
 obvious that the new attempt directly continues work on the same idea, it may be reasonable to return the
 Closed BIP to Draft status.
 
-### Changelog
+### Changelog Section and Version Header
 
 To help implementers understand updates to a BIP, any changes after it has reached Complete must be tracked with version,
 date, and description in a Changelog section sorted by most recent version first. The version number is inspired by semantic versioning (MAJOR.MINOR.PATCH).
@@ -463,7 +464,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 or other community members should comment in regard
 to:
 
 * Novelty of the idea
@@ -481,22 +482,23 @@ 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
+* A draft of the BIP by one of the authors has been previously discussed on the Bitcoin Development Mailing List
 * 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 Layer and Type 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 +524,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.
@@ -598,6 +600,26 @@ The Superseded-By header is replaced with the Proposed-Replacement header in all
 Existing BIPs retain their license terms unchanged.
 The License and License-Code headers of BIPs are updated to express those terms using SPDX License Expressions.
 
+## Changelog
+
+* __1.4.0__ (2025-12-09):
+    * Revert AI guidance, add Changelog section, broaden reference implementation formats, move Type header responsibility to authors, other editorial changes
+* __1.3.1__ (2025-11-10):
+    * Reiterate that numbers are assigned by BIP Editors in pull requests
+* __1.3.0__ (2025-10-22):
+    * Restrict use of AI/LLM tools, require original work.
+* __1.2.1__ (2025-09-19):
+    * Clarify that idea should be discussed on dedicated mailing list thread
+* __1.2.0__ (2025-09-19):
+    * Rename Created header to Assigned to clarify that it holds the date of number assignment
+* __1.1.0__ (2025-07-18):
+    * Switch to SPDX License Expressions, drop License-Code header, and make editorial changes to BIP Licensing section.
+* __1.0.1__ (2025-06-27):
+    * Improve description of acceptance, purpose of the BIPs repository, when Draft BIPs can be closed due to not
+      making progress, and make other minor improvements to phrasing.
+* __1.0.0__ (2025-03-18):
+    * Complete planned work and move to Proposed.
+
 ## Copyright
 
 This BIP is licensed under the [BSD-2-Clause License](https://opensource.org/licenses/BSD-2-Clause). Some content was
@@ -625,9 +647,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.
@@ -641,13 +660,13 @@ feedback, and helpful comments.
     only a handful of contributors commenting at all. This led to many situations in which one or two comments ended up
     dominating the comment summary. While some of those comments may have been representative of broadly held opinions,
     it also overstated the importance of individual comments directly in the Preamble of BIPs. As collecting feedback in
-    this accessible fashion failed, the new process puts the onus back on the audience to make their own evaluation.
+    this accessible fashion failed, the new process puts the burden back on the audience to make their own evaluation.
 [^layer]: **Why is the layer header now permitted for other BIP types?**  
     The layer header had already been used by many Informational BIPs, so the rule that it is only available to
     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 BIP Editors, and frequently led 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?**  

bip-0053.mediawiki

@@ -38,11 +38,11 @@ This has been mitigated by Bitcoin Core's relay policy and the RPC interface sin
 64-byte transactions introduce block malleability. Malicious peers can construct consensus valid and invalid 64-byte
 transactions that have the same serialization as the concatenation of 2 hashes in the Merkle tree.
 
-Assume we have a valid Bitcoin block with 2 transactions in it that have transaction ids of T<sub>0</sub> and T<sub>1</sub>.
-The Merkle root for this block is H(T<sub>0</sub>||T<sub>1</sub>).
-A malicious user could find a 64-byte transaction T<sub>m</sub> that serializes to T<sub>0</sub>||T<sub>1</sub>.
+Assume we have a valid Bitcoin block with 2 transactions in it with Txid<sub>0</sub> and Txid<sub>1</sub>.
+The Merkle root for this block is H(Txid<sub>0</sub>||Txid<sub>1</sub>).
+A malicious user could find a 64-byte transaction T<sub>m</sub> that serializes to Txid<sub>0</sub>||Txid<sub>1</sub>.
 Next that user relays the block containing the malicious T<sub>m</sub> rather than the
-valid Bitcoin transactions that correspond with T<sub>0</sub> and T<sub>1</sub>.
+valid Bitcoin transactions that correspond to Txid<sub>0</sub> and Txid<sub>1</sub>.
 
 ==== Block malleability with consensus INVALID transactions ====
 
@@ -84,7 +84,7 @@ are less constrained than the first 32 bytes) are constructed so that they colli
 with the hash of some other fake, invalid transaction F. The attacker can fool the SPV client into believing that F
 was included in a Bitcoin block rather than T with 81 bits<ref>[[bip-0053/2-BitcoinMerkle.pdf|An attacker who can do 81 bits of work (followed by another 40 bits of work, to
 construct the funding transaction whose coins will be spent by this one) is able
-to fool an SPV client in this way.]]</ref> of work. This also reduces implementation complexity for SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a Merkle proof for a transaction is secure.]</ref>.
+to fool an SPV client in this way.]]</ref> of work. Disallowing 64-byte transactions reduces implementation complexity for SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a Merkle proof for a 64-byte transaction is secure.]</ref>.
 
 ==Rationale==
 

bip-0054.md

@@ -143,10 +143,8 @@ the grace period used in this proposal, miners should use the `curtime` or `mint
 according to this proposal. Note this is not a new requirement: using a timestamp lower than the
 `mintime` field from the `getblocktemplate` result already leads to creating an invalid block.
 
-Bitcoin Core as of version 29.0 may relay and create a block template including a transaction that
-violates the signature operations limit introduced in this BIP. A newer version of Bitcoin Core
-that makes this type of transaction non-standard should be widely adopted before this soft fork is
-considered for activation.
+Bitcoin Core version [30.0][Core 30.0] and later will not generate a block template including a
+transaction that violates the signature operations limit introduced in this BIP.
 
 Bitcoin Core version [0.16.1][Core 0.16.1] and later will neither relay nor create block templates
 that include 64-byte transactions.
@@ -156,14 +154,24 @@ knowledge, there does not exist an open source reference broadly in use today fo
 We encourage mining pools to update their software to craft coinbase transactions that are
 forward-compatible with the changes proposed in this BIP.
 
+## Reference implementation
+
+An implementation of BIP54 for Bitcoin Core is available [here][inquisition-implem].
+
+## Test vectors
+
+Documented test vectors are available [here](./bip-0054/test_vectors/) for all mitigations
+introduced in this BIP.
+
 ## Acknowledgements
 
 This document builds upon an [earlier proposal][BIP-XXXX] by Matt Corallo.
 
 The authors would like to thank everyone involved in researching the most appropriate mitigation for
 each of these bugs. We would like to thank in particular Anthony Towns and Sjors Provoost for their
 direct contributions to this proposal, as well as @0xb10c and Brian Groll for providing the authors
-with data to analyze the proposed mitigations.
+with data to analyze the proposed mitigations. Thanks to Chris Stewart for digging up historical
+violations to the new transaction size rule, which are partially reused in this BIP's test vectors.
 
 ## Copyright
 
@@ -234,3 +242,5 @@ notably of Bitcoin Core but also of all other implementations the authors are aw
 [Delving duplicable]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4
 [Core 0.16.1]: https://bitcoincore.org/en/releases/0.16.1
 [Core 29.0]: https://bitcoincore.org/en/releases/29.0
+[inquisition-implem]: https://github.com/darosior/bitcoin/tree/2509_inquisition_consensus_cleanup
+[Core 30.0]: https://bitcoincore.org/en/releases/30.0