PQ opcodes BIP

.github/workflows/github-action-checks.yml

@@ -5,18 +5,18 @@ jobs:
   Link-Format-Checks:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v5
       - run: scripts/link-format-chk.sh
   Build-Table-Checks:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v5
       - run: scripts/buildtable.pl >/tmp/table.mediawiki || exit 1
   Diff-Checks:
     name: "Diff Checks (fails until number assignment)"
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v5
         with:
           fetch-depth: 2
       - run: scripts/diffcheck.sh
@@ -25,7 +25,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout Actions Repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@v5
 
       - name: Check spelling
         uses: crate-ci/typos@master

.typos.toml

@@ -24,6 +24,7 @@ PSBT = "PSBT"
 ser = "ser"
 # Names
 Atack = "Atack"
+Falke = "Falke"
 Meni = "Meni"
 Ono = "Ono"
 

README.mediawiki

@@ -125,13 +125,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Luke Dashjr
 | Standard
 | Replaced
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffcfcf"
 | [[bip-0021.mediawiki|21]]
 | Applications
 | URI Scheme
 | Nils Schneider, Matt Corallo
 | Standard
-| Final
+| Replaced
 |- style="background-color: #cfffcf"
 | [[bip-0022.mediawiki|22]]
 | API/RPC
@@ -609,13 +609,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Gavin Andresen
 | Standard
 | Rejected
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0111.mediawiki|111]]
 | Peer Services
 | NODE_BLOOM service bit
 | Matt Corallo, Peter Todd
 | Standard
-| Proposed
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0112.mediawiki|112]]
 | Consensus (soft fork)
@@ -889,34 +889,34 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Karl-Johan Alm
 | Standard
 | Withdrawn
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0155.mediawiki|155]]
 | Peer Services
 | addrv2 message
 | Wladimir J. van der Laan
 | Standard
-| Draft
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0156.mediawiki|156]]
 | Peer Services
 | Dandelion - Privacy Enhancing Routing
 | Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath
 | Standard
 | Rejected
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0157.mediawiki|157]]
 | Peer Services
 | Client Side Block Filtering
 | Olaoluwa Osuntokun, Alex Akselrod, Jim Posen
 | Standard
-| Draft
-|-
+| Final
+|- style="background-color: #cfffcf"
 | [[bip-0158.mediawiki|158]]
 | Peer Services
 | Compact Block Filters for Light Clients
 | Olaoluwa Osuntokun, Alex Akselrod
 | Standard
-| Draft
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0159.mediawiki|159]]
 | Peer Services
@@ -1036,13 +1036,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | BtcDrak
 | Standard
 | Draft
-|-
+|- style="background-color: #ffffcf"
 | [[bip-0321.mediawiki|321]]
 | Applications
 | URI Scheme
 | Matt Corallo
 | Standard
-| Draft
+| Proposed
 |-
 | [[bip-0322.mediawiki|322]]
 | Applications
@@ -1077,7 +1077,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | MuSig2 for BIP340-compatible Multi-Signatures
 | Jonas Nick, Tim Ruffing, Elliott Jin
 | Informational
-| Active
+| Final
 |- style="background-color: #ffffcf"
 | [[bip-0328.mediawiki|328]]
 | Applications
@@ -1204,13 +1204,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | josibake, Ruben Somsen
 | Standard
 | Proposed
-|-
+|- style="background-color: #ffffcf"
 | [[bip-0353.mediawiki|353]]
 | Applications
 | DNS Payment Instructions
 | Matt Corallo, Bastien Teinturier
 | Standard
-| Draft
+| Proposed
 |- style="background-color: #cfffcf"
 | [[bip-0370.mediawiki|370]]
 | Applications

bip-0002.mediawiki

@@ -359,8 +359,8 @@ In this case, only the acceptable license(s) should be listed in the License and
 
 ====Recommended licenses====
 
-* BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
-* BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
+* BSD-2-Clause: [https://opensource.org/license/BSD-2-Clause OSI-approved BSD 2-clause license]
+* BSD-3-Clause: [https://opensource.org/license/BSD-3-Clause OSI-approved BSD 3-clause license]
 * CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
 * GNU-All-Permissive: [https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
@@ -372,7 +372,7 @@ In addition, it is recommended that literal code included in the BIP be dual-lic
 * BSL-1.0: [https://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
 * CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
 * CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
-* MIT: [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
+* MIT: [https://opensource.org/license/MIT The MIT License]
 * AGPL-3.0+: [https://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
 * FDL-1.3: [https://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]
 * GPL-2.0+: [https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]

bip-0003.md

@@ -37,7 +37,10 @@ Some BIPs describe processes, implementation guidelines, best practices, inciden
 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. BIPs may be submitted by anyone.
+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.
 
 The scope of the BIPs
 repository is limited to BIPs that do not oppose the fundamental principle that Bitcoin constitutes a peer-to-peer
@@ -112,14 +115,14 @@ appear in the following order. Headers marked with "\*" are optional. All other
 ##### Overview
 
 ```
-  BIP: <BIP number, or "?">
+  BIP: <BIP number, or "?" before assignment>
 * Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
   Title: <BIP title (≤ 50 characters)>
   Authors: <Authors’ names and email addresses>
 * Deputies: <Deputies’ names and email addresses>
   Status: <Draft | Complete | Deployed | Closed>
   Type: <Specification | Informational | Process>
-  Created: <Date of number assignment (yyyy-mm-dd), or "?">
+  Assigned: <Date of number assignment (yyyy-mm-dd), or "?" before assignment>
   License: <SPDX License Expression>
 * Discussion: <Noteworthy discussion threads in "yyyy-mm-dd: URL" format>
 * Version: <MAJOR.MINOR.PATCH>
@@ -130,7 +133,7 @@ appear in the following order. Headers marked with "\*" are optional. All other
 
 ##### Header Descriptions
 
-* BIP — The assigned number of the BIP. Please use "?" before a number has been assigned by the BIP Editors.
+* BIP — The assigned number of the BIP (without leading zeros). Please use "?" before a number has been assigned by the BIP Editors.
 * Layer — The layer of Bitcoin the BIP applies to using the BIP classification defined in [BIP 123](bip-0123.mediawiki).
 * Authors — The names (or pseudonyms) and email addresses of all authors of the BIP. The format of each authors header
   value must be
@@ -146,6 +149,7 @@ appear in the following order. Headers marked with "\*" are optional. All other
   Authors header. See the [BIP Ownership](#bip-ownership) section above.
 * Status — The stage of the workflow of the proposal. See the [Workflow](#workflow) section below.
 * Type — See the [BIP Types](#bip-types) section below for a description of the three BIP types.
+* Assigned – The date a BIP was assigned its number. Please use "?" before a number has been assigned by the BIP Editors.
 * License — The License header specifies SPDX License Expressions describing the terms under which the
   BIP and its auxiliary files are available. See the [BIP Licensing](#bip-licensing) section below.
 * Discussion — The Discussion header points the audience to relevant discussions of the BIP, e.g., the mailing list
@@ -424,12 +428,13 @@ acceptable license.
 In other words, a new BIP must specify an SPDX License Expression that is either "L" or equivalent to "L OR E" for some
 acceptable license L from the following list and another SPDX License Expression E.
 
-* BSD-2-Clause: [BSD 2-Clause License](https://opensource.org/licenses/BSD-2-Clause)
-* BSD-3-Clause: [BSD 3-Clause License](https://opensource.org/licenses/BSD-3-Clause)
+* BSD-2-Clause: [BSD 2-Clause License](https://opensource.org/license/BSD-2-Clause)
+* BSD-3-Clause: [BSD 3-Clause License](https://opensource.org/license/BSD-3-Clause)
 * CC0-1.0: [CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
 * FSFAP: [FSF All Permissive License](https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html)
 * CC-BY-4.0: [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/)
-* MIT: [Expat/MIT/X11 License](https://opensource.org/licenses/MIT)
+* MIT: [The MIT License](https://opensource.org/license/MIT)
+* MIT-0: [MIT No Attribution License](https://opensource.org/license/MIT-0)
 * Apache-2.0: [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0)
 * BSL-1.0: [Boost Software License 1.0](https://www.boost.org/LICENSE_1_0.txt)
 
@@ -475,7 +480,7 @@ 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 discussed on the Bitcoin Development Mailing List
+* The idea has been previously proposed by one of the authors 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
@@ -484,7 +489,7 @@ For each new BIP pull request that comes in, an editor checks the following:
 * 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 BIP is ready: it is comprehensible, technically feasible, and all aspects are addressed as necessary
+* 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.
 
@@ -542,8 +547,9 @@ mentioned in the [Changelog](#changelog) section.
 - The "Superseded-By" header is replaced with the "Proposed-Replacement" header.
 - The "Post-History" header is replaced with the "Discussion" header.
 - The optional "Version" header is introduced.
-- The "Discussions-To" header is dropped as it has never been used in any BIP.
+- The "Discussions-To" header is dropped, as it has never been used in any BIP.
 - The "License-Code" header has been sunset, as it was used by only five BIPs (98, 116, 117, 330, 340) and created more ambiguity than clarity.
+- The "Created" header is renamed to "Assigned", as the header’s value is the date of number assignment.[^assigned]
 - Introduce Deputies and optional "Deputies" header.
 - The BIP "Title" header may now contain up to 50 characters (increased from 44 in BIP 2).
 - The "Layer" header is optional for Specification BIPs or Informational BIPs, as it does not make sense for all BIPs.[^layer]
@@ -612,6 +618,12 @@ feedback, and helpful comments.
 
 ## Rationale
 
+[^assigned]: **Why was the Created header renamed to Assigned?**  
+    Both BIP 1 and BIP 2 described the Created header as "date created on" in the preamble template, but followed that
+    up with "Created header records the date that the BIP was assigned a number" as the description of the field. This
+    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.

bip-0010.mediawiki

@@ -95,7 +95,7 @@ In this transaction, there are two inputs, one of 150 BTC and the other of 12 BT
 
 The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures.  This serialization is compact, and will be interpreted the same in all character encodings.  It can be copied inline into an email, or saved in a text file.  The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP.
 
-A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line.  If that is the last signature required, they can broadcast it themselves.  Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP.  However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it is not the recommended method for combining TxDPs.
+A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line.  If that is the last signature required, they can broadcast it themselves.  Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP.  However, even without the programmatic support, a user could manually combine them by copying the appropriate _SIG_ lines between serializations, though it is not the recommended method for combining TxDPs.
 
 == Reference Implementation ==
 

bip-0016.mediawiki

@@ -58,7 +58,7 @@ Examples:
 +3 signature operations:
     {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG}
 
-+22 signature operations
++22 signature operations:
     {OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF}
 
 ==Rationale==
@@ -74,7 +74,7 @@ The signature operation counting rules are intended to be easy and quick to impl
 There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is:
 
 # Attacker creates a pay-to-script-hash transaction that is valid as seen by old software, but invalid for new implementation, and sends themselves some coins using it.
-# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software.
+# Attacker also creates a standard transaction that spends the pay-to-script-hash transaction, and pays the victim who is running old software.
 # Attacker mines a block that contains both transactions.
 
 If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.
@@ -116,4 +116,5 @@ https://gist.github.com/gavinandresen/3966071
 * [[bip-0016/qa.mediawiki|Quality Assurance test checklist]]
 
 == References ==
-<references>
+
+<references/>

bip-0021.mediawiki

@@ -6,11 +6,18 @@
           Matt Corallo <[email protected]>
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0021
-  Status: Final
+  Status: Replaced
   Type: Standards Track
   Created: 2012-01-29
+  Superseded-By: 321
 </pre>
 
+=Superseded by BIP 321=
+
+This BIP has been superseded and replaced with BIP 321. Please see [[bip-0321.mediawiki|BIP 321]] instead.
+
+=Original BIP=
+
 This BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.
 
 ==Abstract==

bip-0054.md

@@ -8,7 +8,7 @@
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0054
   Status: Draft
   Type: Standards Track
-  Created: 2024-04-11
+  Created: 2025-04-11
   License: CC0-1.0
 ```
 

bip-0070.mediawiki

@@ -302,7 +302,7 @@ Protocol Buffers : https://developers.google.com/protocol-buffers/
 
 ==Reference implementation==
 
-Create Payment Request generator : https://bitcoincore.org/~gavin/createpaymentrequest.php ([[https://github.com/gavinandresen/paymentrequest|source]])
+Create Payment Request generator : https://developer.bitcoin.org/examples/payment_processing.html ([[https://github.com/gavinandresen/paymentrequest|source]])
 
 BitcoinJ : https://bitcoinj.github.io/payment-protocol#introduction