Merge branch 'master' into cat

Author: murchandamus

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

@@ -5,15 +5,18 @@ jobs:
   Link-Format-Checks:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - run: scripts/link-format-chk.sh
   Build-Table-Checks:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - 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@v3
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 2
       - run: scripts/diffcheck.sh

.gitignore

@@ -0,0 +1,6 @@
+bip-0174/coinjoin-workflow.aux
+bip-0174/coinjoin-workflow.log
+bip-0174/coinjoin-workflow.pdf
+bip-0174/multisig-workflow.aux
+bip-0174/multisig-workflow.log
+bip-0174/multisig-workflow.pdf

README.mediawiki

@@ -1,4 +1,4 @@
-People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [email protected]] mailing list (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
+People wishing to submit BIPs, first should propose their idea or document to the [https://groups.google.com/g/bitcoindev [email protected]] mailing list (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
 
 We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
 
@@ -235,29 +235,29 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Applications
 | Purpose Field for Deterministic Wallets
 | Marek Palatinus, Pavol Rusnak
-| Informational
+| Standard
 | Final
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0044.mediawiki|44]]
 | Applications
 | Multi-Account Hierarchy for Deterministic Wallets
 | Marek Palatinus, Pavol Rusnak
 | Standard
-| Proposed
+| Final
 |- style="background-color: #ffffcf"
 | [[bip-0045.mediawiki|45]]
 | Applications
 | Structure for Deterministic P2SH Multisignature Wallets
 | Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia
 | Standard
 | Proposed
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0047.mediawiki|47]]
 | Applications
 | Reusable Payment Codes for Hierarchical Deterministic Wallets
 | Justus Ranvier
 | Informational
-| Draft
+| Final
 |- style="background-color: #ffffcf"
 | [[bip-0048.mediawiki|48]]
 | Applications
@@ -270,7 +270,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Applications
 | Derivation scheme for P2WPKH-nested-in-P2SH based accounts
 | Daniel Weigl
-| Informational
+| Standard
 | Final
 |- style="background-color: #cfffcf"
 | [[bip-0050.mediawiki|50]]
@@ -434,12 +434,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Eric Lombrozo
 | Standard
 | Rejected
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0084.mediawiki|84]]
 | Applications
 | Derivation scheme for P2WPKH based accounts
 | Pavol Rusnak
-| Informational
+| Standard
 | Final
 |-
 | [[bip-0085.mediawiki|85]]
@@ -452,7 +452,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0086.mediawiki|86]]
 | Applications
 | Key Derivation for Single Key P2TR Outputs
-| Andrew Chow
+| Ava Chow
 | Standard
 | Draft
 |- style="background-color: #ffffcf"
@@ -487,7 +487,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0093.mediawiki|93]]
 | Applications
 | codex32: Checksummed SSSS-aware BIP32 seeds
-| Leon Olsson Curr, Pearlwort Sneed
+| Leon Olsson Curr, Pearlwort Sneed, Andrew Poelstra
 | Informational
 | Draft
 |-
@@ -627,7 +627,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0119.mediawiki|119]]
 | Consensus (soft fork)
 | CHECKTEMPLATEVERIFY
-| Jeremy Rubin
+| Jeremy Rubin, James O'Beirne
 | Standard
 | Draft
 |- style="background-color: #ffcfcf"
@@ -714,13 +714,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Andy Chase
 | Process
 | Withdrawn
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0133.mediawiki|133]]
 | Peer Services
 | feefilter message
 | Alex Morcos
 | Standard
-| Draft
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0134.mediawiki|134]]
 | Consensus (hard fork)
@@ -900,7 +900,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0174.mediawiki|174]]
 | Applications
 | Partially Signed Bitcoin Transaction Format
-| Andrew Chow
+| Ava Chow
 | Standard
 | Final
 |- style="background-color: #ffcfcf"
@@ -1030,6 +1030,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0331.mediawiki|331]]
+| Peer Services
+| Ancestor Package Relay
+| Gloria Zhao
+| Standard
+| Draft
+|-
 | [[bip-0338.mediawiki|338]]
 | Peer Services
 | Disable transaction relay message
@@ -1072,13 +1079,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Final
 |-
+| [[bip-0345.mediawiki|345]]
+| Consensus (soft fork)
+| OP_VAULT
+| James O'Beirne, Greg Sanders, Anthony Towns
+| Standard
+| Draft
+|-
 | [[bip-0347.mediawiki|347]]
 | Consensus (soft fork)
 | OP_CAT in Tapscript
 | Ethan Heilman, Armin Sabouri
 | Standard
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0350.mediawiki|350]]
 | Applications
 | Bech32m format for v1+ witness addresses
@@ -1096,14 +1110,14 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0370.mediawiki|370]]
 | Applications
 | PSBT Version 2
-| Andrew Chow
+| Ava Chow
 | Standard
 | Draft
 |-
 | [[bip-0371.mediawiki|371]]
 | Applications
 | Taproot Fields for PSBT
-| Andrew Chow
+| Ava Chow
 | Standard
 | Draft
 |-
@@ -1117,56 +1131,56 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0380.mediawiki|380]]
 | Applications
 | Output Script Descriptors General Operation
-| Pieter Wuille, Andrew Chow
+| Pieter Wuille, Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0381.mediawiki|381]]
 | Applications
 | Non-Segwit Output Script Descriptors
-| Pieter Wuille, Andrew Chow
+| Pieter Wuille, Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0382.mediawiki|382]]
 | Applications
 | Segwit Output Script Descriptors
-| Pieter Wuille, Andrew Chow
+| Pieter Wuille, Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0383.mediawiki|383]]
 | Applications
 | Multisig Output Script Descriptors
-| Pieter Wuille, Andrew Chow
+| Pieter Wuille, Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0384.mediawiki|384]]
 | Applications
 | combo() Output Script Descriptors
-| Pieter Wuille, Andrew Chow
+| Pieter Wuille, Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0385.mediawiki|385]]
 | Applications
 | raw() and addr() Output Script Descriptors
-| Pieter Wuille, Andrew Chow
+| Pieter Wuille, Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0386.mediawiki|386]]
 | Applications
 | tr() Output Script Descriptors
-| Pieter Wuille, Andrew Chow
+| Pieter Wuille, Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0389.mediawiki|389]]
 | Applications
 | Multipath Descriptor Key Expressions
-| Andrew Chow
+| Ava Chow
 | Informational
 | Draft
 |}

bip-0002.mediawiki

@@ -32,13 +32,13 @@ The BIP process begins with a new idea for Bitcoin. Each potential BIP must have
 Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a BIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker.
 Additionally, many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons.
 The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression.
-After investigating past work, the best way to proceed is by posting about the new idea to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list].
+After investigating past work, the best way to proceed is by posting about the new idea to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list].
 
 Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time.
 Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick).
 It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.
 
-Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list].
+Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list].
 This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal.
 Following a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request.
 This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
@@ -67,8 +67,12 @@ If you are interested in assuming ownership of a BIP, send a message asking to t
 
 The current BIP editors are:
 
+* Bryan Bishop ([[mailto:[email protected]|[email protected]]])
+* Jon Atack ([[mailto:[email protected]|[email protected]]])
 * Luke Dashjr ([[mailto:[email protected]|[email protected]]])
-* Kalle Alm ([[mailto:[email protected]|[email protected]]])
+* Mark "Murch" Erhardt ([[mailto:[email protected]|[email protected]]])
+* Olaoluwa Osuntokun ([[mailto:[email protected]|[email protected]]])
+* Ruben Somsen ([[mailto:[email protected]|[email protected]]])
 
 ===BIP Editor Responsibilities & Workflow===
 
@@ -98,11 +102,13 @@ The BIP editor will:
 
 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 correcting misspellings, fixing broken links, etc.
+
 ==BIP format and structure==
 
 ===Specification===
 
-BIPs should be written in mediawiki format.
+BIPs should be written in mediawiki or markdown format.
 
 Each BIP should have the following parts:
 
@@ -409,7 +415,6 @@ Why is Public Domain no longer acceptable for new BIPs?
 * Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
 * Email addresses are now required for authors.
 * The Post-History header may be provided as a link instead of a simple date.
-* Markdown format is no longer permitted for BIPs.
 * The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions.
 
 ==See Also==

bip-0009/states.gv

@@ -0,0 +1,22 @@
+/*   There are many ways to compile this, but one of them is:
+ *
+ *     $ dot -Tpng states.gv -o states.png
+ */
+digraph {
+  /*   States. */
+  DEFINED; FAILED; STARTED; LOCKED_IN; ACTIVE;
+
+  /*   Relationships between states, labeled where applicable. */
+  DEFINED -> DEFINED;
+  DEFINED -> FAILED [label = "timeout ≤ MTP"];
+  DEFINED -> STARTED [label = "starttime ≤ MTP < timeout"];
+  FAILED -> FAILED;
+  STARTED -> STARTED;
+  STARTED -> FAILED [label = "timeout ≤ MTP"];
+  STARTED -> LOCKED_IN [label = "(MTP < timeout) AND (threshold reached)"];
+  LOCKED_IN -> ACTIVE [label = "Always"];
+  ACTIVE -> ACTIVE;
+
+  /*   Visualization hack to unclutter output. */
+  nodesep = 1.2;
+}

bip-0009/states.png

@@ -93,10 +93,10 @@ The following is an example TxDP from Armory, produced while running on the test
 
 In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC.  This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005.  In this TxDP, both inputs have been signed, and thus could broadcast immediately.
 
-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 interpretted 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.
+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.
 
 == Reference Implementation ==
 
-This proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of verion 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format.
+This proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of version 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format.

bip-0010.mediawiki

@@ -43,11 +43,11 @@ OP_EVAL allows the receiver of bitcoins to specify how they can be spent when th
 
 If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver.
 
-The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties.
+The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilities.
 
 That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure.
 
-There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is:
+There is a 1-confirmation attack on old clients that interpret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is:
 
 # Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients.
 # Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim.

bip-0012.mediawiki

@@ -28,7 +28,7 @@ Version bumping can also introduce incompatibilities and fracture the network. I
 
 By using a protocol version, we set all implementations on the network to a common standard. Everybody is able to agree within their confines what is protocol and what is implementation-dependent. A user agent string is offered as a 'vanity-plate' for clients to distinguish themselves in the network.
 
-Separation of the network protocol from the implemention, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type).
+Separation of the network protocol from the implementation, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type).
 
 User agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems. In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form. The user agent does not provide a method for clients to work around and behave differently to different implementations, as this will lead to protocol fracturing.