Merge branch 'master' into add-bip40

Author: ben221199

.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]]
@@ -439,7 +439,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Applications
 | Derivation scheme for P2WPKH based accounts
 | Pavol Rusnak
-| Informational
+| Standard
 | Final
 |-
 | [[bip-0085.mediawiki|85]]
@@ -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)
@@ -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
@@ -1078,6 +1085,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | 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

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,6 +102,8 @@ 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===
@@ -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

@@ -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.
 

bip-0014.mediawiki

@@ -348,7 +348,7 @@ By using DNS lookups, the MITM problem with IP transactions could be mitigated b
 
 === Namecoin ID ===
 
-This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retreives the structured data containing the bitcoin address(es) associated with this alias.
+This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retrieves the structured data containing the bitcoin address(es) associated with this alias.
 
 Using a decentralised domain name system like Namecoin, means no external server or entity needs to be trusted unlike the other proposals listed here. This indicates a system with the advantage of having a high availability and ease of entry (no restrictions for users to create aliases).
 
@@ -401,4 +401,4 @@ Any text can be put into the brackets, allowing merchants to adapt it to all the
 New features can be added later to support uncovered cases.
 
 
-See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations.
+See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more information.

bip-0015.mediawiki

@@ -37,7 +37,7 @@ Elements of the query component may contain characters outside the valid range.
 
 === ABNF grammar ===
 
-(See also [[#Simpler syntax|a simpler representation of syntax]])
+(See also [[#simpler-syntax|a simpler representation of syntax]])
 
  bitcoinurn     = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]
  bitcoinaddress = *base58
@@ -120,11 +120,6 @@ Some future version that has variables which are (currently) not understood but
 
 Characters must be URI encoded properly.
 
-== Reference Implementations ==
-=== Bitcoin clients ===
-* Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.
+== Reference Implementation ==
 
-=== Libraries ===
-* Javascript - https://github.com/bitcoinjs/bip21
-* Java - https://github.com/SandroMachado/BitcoinPaymentURI
-* Swift - https://github.com/SandroMachado/BitcoinPaymentURISwift
+Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.