Merge branch 'master' into bip78-mixed-inputs-ok

2025-02-22 06:52:38 +01:00 · 2025-01-14 08:13:20 -07:00 · 2025-01-14 08:13:20 -07:00 · f1ad9188b4
commit f1ad9188b4
parent bd01a269e5 2f862f75d1
138 changed files with 9872 additions and 809 deletions
--- a/.github/workflows/github-action-checks.yml
+++ b/.github/workflows/github-action-checks.yml
@ -20,3 +20,12 @@ jobs:
        with:
          fetch-depth: 2
      - run: scripts/diffcheck.sh
  Typo-Checks:
    name: "Typo Checks"
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Actions Repository
        uses: actions/checkout@v4
      - name: Check spelling
        uses: crate-ci/typos@master
--- a/.typos.toml
+++ b/.typos.toml
@ -0,0 +1,44 @@
 [default]
 extend-ignore-re = [
    # NOTE: use here for regex patterns
    "xpub.*",
    "xprv.*",
    "3.*", # address
    "5.*", # address
    "private_key .*",
    "privkey .*",
    "tt.*", # <tt> tags
    "code.*", # <code> tags
    "\\w*<sub>", # prefix for <sub> tags
    "OP_SUCCESSx|\\d+",
    "pay.*",
    "ser.*",
    "prefix.*",
    "value: .*",
 ]
 [default.extend-words]
 # NOTE: use here for false-positives
 anc = "anc"
 PSBT = "PSBT"
 ser = "ser"
 # Names
 Atack = "Atack"
 Meni = "Meni"
 Ono = "Ono"
 [files]
 extend-exclude = [
    "/*/*.csv",
    "/*.d*",
    "/*/*.d*",
    "/*/*.go",
    "/*/*.json",
    "/*/*/*.json",
    "/*/*.mod",
    "/*/*.proto",
    "/*/*.py",
    "scripts",
    "/*/*.s*",
    "/*/*.t*",
 ]
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@ -0,0 +1,12 @@
 # Contributing Guidelines
 Apart from following [BIP 2](./bip-0002.mediawiki),
 we do CI checks to ensure that the proposed BIPs do not have common typos.
 These checks are done using [`typos`](https://github.com/crate-ci/typos).
 To check for typos locally,
 install [`typos`](https://github.com/crate-ci/typos)
 and then run in the root directory:
 ```bash
 typos
 ```
--- a/README.mediawiki
+++ b/README.mediawiki
@ -202,13 +202,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Mike Caldwell, Aaron Voisine
 | Standard
 | Draft
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0039.mediawiki|39]]
 | Applications
 | Mnemonic code for generating deterministic keys
 | Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe
 | Standard
-| Proposed
+| Final
 |-
 | 40
 | API/RPC
@ -251,6 +251,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia
 | Standard
 | Proposed
 |-
 | [[bip-0046.mediawiki|46]]
 | Applications
 | Address Scheme for Timelocked Fidelity Bonds
 | Chris Belcher, Thebora Kompanioni
 | Standard
 | Draft
 |- style="background-color: #cfffcf"
 | [[bip-0047.mediawiki|47]]
 | Applications
@ -441,20 +448,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pavol Rusnak
 | Standard
 | Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0085.mediawiki|85]]
 | Applications
 | Deterministic Entropy From BIP32 Keychains
-| Ethan Kosakovsky
+| Ethan Kosakovsky, Aneesh Karve
 | Informational
-| Draft
+| Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0086.mediawiki|86]]
 | Applications
 | Key Derivation for Single Key P2TR Outputs
 | Ava Chow
 | Standard
-| Draft
+| Final
 |- style="background-color: #ffffcf"
 | [[bip-0087.mediawiki|87]]
 | Applications
@ -491,6 +498,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |-
 | [[bip-0094.mediawiki|94]]
 | Applications
 | Testnet 4
 | Fabian Jahr
 | Standard
 | Draft
 |-
 | [[bip-0098.mediawiki|98]]
 | Consensus (soft fork)
 | Fast Merkle Trees
@ -627,7 +641,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0119.mediawiki|119]]
 | Consensus (soft fork)
 | CHECKTEMPLATEVERIFY
-| Jeremy Rubin, James O'Beirne
+| Jeremy Rubin
 | Standard
 | Draft
 |- style="background-color: #ffcfcf"
@ -665,13 +679,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Eric Lombrozo, William Swanson
 | Informational
 | Rejected
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0125.mediawiki|125]]
 | Applications
 | Opt-in Full Replace-by-Fee Signaling
 | David A. Harding, Peter Todd
 | Standard
-| Proposed
+| Final
 |-
 | [[bip-0126.mediawiki|126]]
 |
@ -693,13 +707,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen, Rodolfo Novak
 | Standard
 | Proposed
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0130.mediawiki|130]]
 | Peer Services
 | sendheaders message
 | Suhas Daftuar
 | Standard
-| Proposed
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0131.mediawiki|131]]
 | Consensus (hard fork)
@ -825,7 +839,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Peer Authentication
 | Jonas Schnelli
 | Standard
-| Draft
+| Deferred
 |- style="background-color: #ffcfcf"
 | [[bip-0151.mediawiki|151]]
 | Peer Services
@ -875,13 +889,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Olaoluwa Osuntokun, Alex Akselrod
 | Standard
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0159.mediawiki|159]]
 | Peer Services
 | NODE_NETWORK_LIMITED service bit
 | Jonas Schnelli
 | Standard
-| Draft
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0171.mediawiki|171]]
 | Applications
@ -987,13 +1001,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Karl-Johan Alm
 | Standard
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0324.mediawiki|324]]
 | Peer Services
 | Version 2 P2P Encrypted Transport Protocol
 | Dhruv Mehta, Tim Ruffing, Jonas Schnelli, Pieter Wuille
 | Standard
-| Draft
+| Final
 |- style="background-color: #ffffcf"
 | [[bip-0325.mediawiki|325]]
 | Applications
@ -1008,12 +1022,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Chris Belcher
 | Informational
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0327.mediawiki|327]]
 |
 | MuSig2 for BIP340-compatible Multi-Signatures
 | Jonas Nick, Tim Ruffing, Elliott Jin
 | Informational
 | Active
 |-
 | [[bip-0328.mediawiki|328]]
 | Applications
 | Derivation Scheme for MuSig2 Aggregate Keys
 | Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0329.mediawiki|329]]
@ -1037,19 +1058,26 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
 | [[bip-0337.mediawiki|337]]
 | API/RPC
 | Compressed Transactions
 | Tom Briar
 | Standard
 | Draft
 |- style="background-color: #ffcfcf"
 | [[bip-0338.mediawiki|338]]
 | Peer Services
 | Disable transaction relay message
 | Suhas Daftuar
 | Standard
-| Draft
+| Withdrawn
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0339.mediawiki|339]]
 | Peer Services
 | WTXID-based transaction relay
 | Suhas Daftuar
 | Standard
-| Draft
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0340.mediawiki|340]]
 |
@ -1082,7 +1110,28 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0345.mediawiki|345]]
 | Consensus (soft fork)
 | OP_VAULT
-| James O'Beirne, Greg Sanders, Anthony Towns
+| James O'Beirne, Greg Sanders
 | Standard
 | Draft
 |-
 | [[bip-0347.mediawiki|347]]
 | Consensus (soft fork)
 | OP_CAT in Tapscript
 | Ethan Heilman, Armin Sabouri
 | Standard
 | Draft
 |-
 | [[bip-0348.md|348]]
 | Consensus (soft fork)
 | CHECKSIGFROMSTACK
 | Brandon Black, Jeremy Rubin
 | Standard
 | Draft
 |-
 | [[bip-0349.md|349]]
 | Consensus (soft fork)
 | OP_INTERNALKEY
 | Brandon Black, Jeremy Rubin
 | Standard
 | Draft
 |- style="background-color: #cfffcf"
@ -1099,20 +1148,34 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Alfred Hodler, Clark Moody
 | Informational
 | Draft
 |- style="background-color: #ffffcf"
 | [[bip-0352.mediawiki|352]]
 | Applications
 | Silent Payments
 | josibake, Ruben Somsen
 | Standard
 | Proposed
 |-
 | [[bip-0353.mediawiki|353]]
 | Applications
 | DNS Payment Instructions
 | Matt Corallo, Bastien Teinturier
 | Standard
 | Draft
 |- style="background-color: #cfffcf"
 | [[bip-0370.mediawiki|370]]
 | Applications
 | PSBT Version 2
 | Ava Chow
 | Standard
-| Draft
+| Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0371.mediawiki|371]]
 | Applications
 | Taproot Fields for PSBT
 | Ava Chow
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0372.mediawiki|372]]
 | Applications
@ -1121,54 +1184,96 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
 | [[bip-0373.mediawiki|373]]
 | Applications
 | MuSig2 PSBT Fields
 | Ava Chow
 | Standard
 | Draft
 |-
 | [[bip-0374.mediawiki|374]]
 | Applications
 | Discrete Log Equality Proofs
 | Andrew Toth, Ruben Somsen, Sebastian Falbesoner
 | Standard
 | Draft
 |-
 | [[bip-0375.mediawiki|375]]
 | Applications
 | Sending Silent Payments with PSBTs
 | Andrew Toth, Ava Chow, josibake
 | Standard
 | Draft
 |-
 | [[bip-0379.md|379]]
 | Applications
 | Miniscript
 | Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Antoine Poinsot, Ava Chow
 | Informational
 | Draft
 |- style="background-color: #cfffcf"
 | [[bip-0380.mediawiki|380]]
 | Applications
 | Output Script Descriptors General Operation
 | Pieter Wuille, Ava Chow
 | Informational
-| Draft
+| Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0381.mediawiki|381]]
 | Applications
 | Non-Segwit Output Script Descriptors
 | Pieter Wuille, Ava Chow
 | Informational
-| Draft
+| Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0382.mediawiki|382]]
 | Applications
 | Segwit Output Script Descriptors
 | Pieter Wuille, Ava Chow
 | Informational
-| Draft
+| Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0383.mediawiki|383]]
 | Applications
 | Multisig Output Script Descriptors
 | Pieter Wuille, Ava Chow
 | Informational
-| Draft
+| Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0384.mediawiki|384]]
 | Applications
 | combo() Output Script Descriptors
 | Pieter Wuille, Ava Chow
 | Informational
-| Draft
+| Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0385.mediawiki|385]]
 | Applications
 | raw() and addr() Output Script Descriptors
 | Pieter Wuille, Ava Chow
 | Informational
-| Draft
+| Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0386.mediawiki|386]]
 | Applications
 | tr() Output Script Descriptors
 | Pieter Wuille, Ava Chow
 | Informational
-| Draft
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0387.mediawiki|387]]
 | Applications
 | Tapscript Multisig Output Script Descriptors
 | Pieter Wuille, Ava Chow
 | Informational
 | Final
 |- style="background-color: #ffffcf"
 | [[bip-0388.mediawiki|388]]
 | Applications
 | Wallet Policies for Descriptor Wallets
 | Salvatore Ingala
 | Standard
 | Proposed
 |-
 | [[bip-0389.mediawiki|389]]
 | Applications
@ -1176,6 +1281,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0390.mediawiki|390]]
 | Applications
 | musig() Descriptor Key Expression
 | Ava Chow
 | Informational
 | Draft
 |-
 | [[bip-0431.mediawiki|431]]
 | Applications
 | Topology Restrictions for Pinning
 | Gloria Zhao
 | Informational
 | Draft
 |}
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@ -362,28 +362,28 @@ In this case, only the acceptable license(s) should be listed in the License and
 * 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]
 * CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
-* GNU-All-Permissive: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
+* GNU-All-Permissive: [https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 ====Not recommended, but acceptable licenses====
-* Apache-2.0: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
+* Apache-2.0: [https://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
-* BSL-1.0: [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
+* 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]
-* AGPL-3.0+: [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
+* 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: [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]
+* FDL-1.3: [https://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]
-* GPL-2.0+: [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
+* GPL-2.0+: [https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
-* LGPL-2.1+: [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
+* LGPL-2.1+: [https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
 ====Not acceptable licenses====
 All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal unless a later BIP extends this one to add them.
 However, BIPs predating the acceptance of this BIP were allowed under other terms, and should use these abbreviation when no other license is granted:
-* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0]
+* OPL: [https://opencontent.org/openpub/ Open Publication License, version 1.0]
 * PD: Released into the public domain
 ===Rationale===
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@ -119,7 +119,7 @@ other one simultaneously transitions to STARTED, which would mean both would dem
 Note that a block's state never depends on its own nVersion; only on that of its ancestors.
-        case STARTED: 
+        case STARTED:
            if (GetMedianTimePast(block.parent) >= timeout) {
                return FAILED;
            }
--- a/bip-0015.mediawiki
+++ b/bip-0015.mediawiki
@ -36,7 +36,7 @@ Their FirstBits alias becomes:
 It is enough information to be given the FirstBits alias ''1brmlab''. When someone wishes to make a purchase, without FirstBits, they either have to type out their address laboriously by hand, scan their QR code (which requires a mobile handset that this author does not own) or find their address on the internet to copy and paste into the client to send bitcoins. FirstBits alleviates this impracticality by providing an easy method to make payments.
-Together with [[vanitygen|Vanitygen (vanity generator)]], it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.
+Together with Vanitygen (vanity generator), it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.
 However FirstBits has its own problems. One is that the possible aliases one is able to generate is limited by the available computing power available. It may not be feasible to generate a complete or precise alias that is wanted- only approximates may be possible. It is also computationally resource intensive which means a large expenditure of power for generating unique aliases in the future, and may not scale up to the level of individuals at home or participants with hand-held devices in an environment of ubiquitous computing.
@ -208,7 +208,7 @@ NameResolutionService::~NameResolutionService()
 void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain)
 {
-    // split address at @ furthrest to the right
+    // split address at @ furthest to the right
    size_t nPosAtsym = strHandle.rfind('@');
    strNickname = strHandle.substr(0, nPosAtsym);
    strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size());
--- a/bip-0017.mediawiki
+++ b/bip-0017.mediawiki
@ -86,7 +86,7 @@ Avoiding a block-chain split by malicious pay-to-script transactions requires ca
 * A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.
-To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time. 
+To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
 To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create.
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@ -36,10 +36,10 @@ Password and passphrase-protected private keys enable new practical use cases fo
 This proposal is hereby placed in the public domain.
 ==Rationale==
-:'''''User story:''' As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.''
+:'' '''User story:''' As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.''
-:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds.  I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
+:'' '''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds.  I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
-:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key.  I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
+:'' '''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key.  I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
-:'''''User story:''' (EC-multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.
+:'' '''User story:''' (EC-multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.''
 ==Specification==
 This proposal makes use of the following functions and definitions:
@ -47,12 +47,12 @@ This proposal makes use of the following functions and definitions:
 *'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining.  Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
 *'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
 *'''scrypt''': A well-known key derivation algorithm.  It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
-*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
+*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the secp256k1 elliptic curve.
-*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve.  G is an elliptic curve point, and N is a large positive integer.
+*'''G, N''': Constants defined as part of the secp256k1 elliptic curve.  G is an elliptic curve point, and N is a large positive integer.
-*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.
+*'''Base58Check''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.
 ===Prefix===
-It is proposed that the resulting Base58Check-encoded string start with a '6'.  The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.
+It is proposed that the resulting Base58Check-encoded string start with a '6'.  The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in Wallet Import Format which denotes an unencrypted private key.
 It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.
@ -64,7 +64,7 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
 * How the user sees it: 58 characters always starting with '6P'
 ** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
 * Count of payload bytes (beyond prefix): 37
-** 1 byte (''flagbyte''): 
+** 1 byte (''flagbyte''):
 *** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact.  For non-EC-multiplied keys, the bits are 11.  For EC-multiplied keys, the bits are 00.
 *** the bit with value 0x20 when set indicates the key should be converted to a base58check encoded P2PKH bitcoin address using the DER compressed public key format. When not set, it should be a base58check encoded P2PKH bitcoin address using the DER uncompressed public key format.
 *** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors.  These bits must be 0 to comply with this version of the specification.
@ -75,10 +75,10 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
 **16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
 * Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
 ** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
-** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's) 
+** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
 * Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
 ** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
-** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's) 
+** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
 * Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
 ** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
 ** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
@ -184,7 +184,7 @@ To recalculate the address:
 # Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash.  If not, report that the passphrase entry was incorrect.
 ==Backwards compatibility==
-Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]].  It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.
+Backwards compatibility is minimally applicable since this is a new standard that at most extends Wallet Import Format. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and Wallet Import Format); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.
 ==Suggestions for implementers of proposal with alt-chains==
 If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.
@ -209,14 +209,10 @@ The preliminary values of 16384, 8, and 8 are hoped to offer the following prope
 ==Reference implementation==
 Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:
-* via https: https://casascius.com/btcaddress-alpha.zip
+* https://github.com/casascius/Bitcoin-Address-Utility
 * at github: https://github.com/casascius/Bitcoin-Address-Utility
 Click "Tools" then "PPEC Keygen" (provisional name)
 ==Other implementations==
 * Javascript - https://github.com/bitcoinjs/bip38
 ==Test vectors==
 ===No compression, no EC multiply===
@ -276,7 +272,7 @@ Test 2:
 Test 1:
 *Passphrase: MOLON LABE
-*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX 
+*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
 *Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
 *Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
 *Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
@ -284,9 +280,9 @@ Test 1:
 *Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
 *Lot/Sequence: 263183/1
-Test 2: 
+Test 2:
 *Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
-*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK 
+*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
 *Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
 *Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
 *Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@ -8,7 +8,7 @@
          Sean Bowe <ewillbefull@gmail.com>
  Comments-Summary: Unanimously Discourage for implementation
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039
-  Status: Proposed
+  Status: Final
  Type: Standards Track
  Created: 2013-09-10
 </pre>
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@ -28,7 +28,7 @@ for two smaller words (This would be a problem with any of the 3 character sets
 ### Spanish
-1. Words can be uniquely determined typing the first 4 characters (sometimes less).
+1. Words can be uniquely determined by typing the first 4 characters (sometimes less).
 2. Special Spanish characters like 'ñ', 'ü', 'á', etc... are considered equal to 'n', 'u', 'a', etc... in terms of identifying a word. Therefore, there is no need to use a Spanish keyboard to introduce the passphrase, an application with the Spanish wordlist will be able to identify the words after the first 4 chars have been typed even if the chars with accents have been replaced with the equivalent without accents.
@ -76,7 +76,7 @@ Words chosen using the following rules:
 6. No plural words.
 7. No words that remind negative/sad/bad things.
 8. If both female/male words are available, choose male version.
-9. No words with double vocals (like: lineetta).
+9. No words with double vowels (like: lineetta).
 10. No words already used in other language mnemonic sets.
 11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters.
 12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must not be the same sequence of 3 or more letters.
@ -92,7 +92,7 @@ Credits: @zizelevak (Jan Lansky zizelevak@gmail.com)
 Words chosen using the following rules:
 1.  Words are 4-8 letters long.
-2.  Words can be uniquely determined typing the first 4 letters.
+2.  Words can be uniquely determined by typing the first 4 letters.
 3.  Only words containing all letters without diacritical marks. (It was the hardest task, because one third of all Czech letters has diacritical marks.)
 4.  Only nouns, verbs and adverbs, no other word types. All words are in basic form.
 5.  No personal names or geographical names.
@ -104,7 +104,7 @@ Words chosen using the following rules:
 Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @Trimegistus
-1. Words can be uniquely determined typing the first 4 characters.
+1. Words can be uniquely determined by typing the first 4 characters.
 2. No accents or special characters.
 3. No complex verb forms.
 4. No plural words, unless there's no singular form.
--- a/bip-0042.mediawiki
+++ b/bip-0042.mediawiki
@ -42,7 +42,7 @@ Note that several other programming languages do not exhibit this behaviour, mak
 ===Floating-point approximation===
-An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript. 
+An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.
 ===Truncation===
--- a/bip-0046.mediawiki
+++ b/bip-0046.mediawiki
@ -0,0 +1,193 @@
 <pre>
  BIP: 46
  Layer: Applications
  Title: Address Scheme for Timelocked Fidelity Bonds
  Author: Chris Belcher <belcher@riseup.net>
          Thebora Kompanioni <theborakompanioni+bip46@gmail.com>
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0046
  Status: Draft
  Type: Standards Track
  Created: 2022-04-01
  License: CC0-1.0
  Post-History: 2022-05-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html
 </pre>
 == Abstract ==
 This BIP defines the derivation scheme for HD wallets which create timelocked addresses used for creating fidelity bonds. It also gives advice to wallet developers on how to use fidelity bonds to sign over messages, such as certificates, which are needed when using fidelity bonds that are stored offline.
 == Copyright ==
 This document is licensed under the Creative Commons CC0 1.0 Universal license.
 == Motivation ==
 Fidelity bonds are used to resist sybil attacks in certain decentralized anonymous protocols. They are created by locking up bitcoins using the `OP_CHECKLOCKTIMEVERIFY` opcode.
 Having a common derivation scheme allows users of wallet software to have a backup of their fidelity bonds by storing only the HD seed and a reference to this BIP. Importantly the user does not need to backup any timelock values.
 We largely use the same approach used in BIPs 49, 84 and 86 for ease of implementation.
 This allows keeping the private keys of fidelity bonds in cold storage, which increases the sybil resistance of a system without hot wallet risk.
 == Backwards Compatibility ==
 This BIP is not backwards compatible by design as described in the Considerations section of [[bip-0049.mediawiki|BIP 49]]. An incompatible wallet will not discover fidelity bonds at all and the user will notice that something is wrong.
 == Background ==
 === Fidelity bonds ===
 A fidelity bond is a mechanism where bitcoin value is deliberately sacrificed to make a cryptographic identity expensive to obtain. A way to create a fidelity bond is to lock up bitcoins by sending them to a timelocked address. The valuable thing being sacrificed is the time-value-of-money.
 The sacrifice must be done in a way that can be proven to a third party. This proof can be made by showing the UTXO outpoint, the address redeemscript and a signature which signs a message using the private key corresponding to the public key in the redeemscript.
 The sacrificed value is an objective measurement that can't be faked and which can be verified by anybody (just like, for example PoW mining). Sybil attacks can be made very expensive by forcing a hypothetical sybil attacker to lock up many bitcoins for a long time. JoinMarket implements fidelity bonds for protection from sybil attackers. At the time of writing over 600 BTC in total have been locked up with some for many years. Their UTXOs and signatures have been advertised to the world as proof. We can calculate that for a sybil attacker to succeed in unmixing all the CoinJoins, they would have to lock up over 100k BTC for several years.
 === Fidelity bonds in cold storage ===
 To allow for holding fidelity bonds in cold storage, there is an intermediate keypair called the certificate.
    UTXO key ---signs---> certificate ---signs---> endpoint
 Where the endpoint might be a IRC nickname or Tor onion hostname. The certificate keypair can be kept online and used to prove ownership of the fidelity bond. Even if the hot wallet private keys are stolen, the coins in the timelocked address will still be safe, although the thief will be able to impersonate the fidelity bond until the expiry.
 == Rationale ==
 It is useful for the user to avoid having to keep a record of the timelocks in the time-locked addresses. So only a limited small set of timelocks are defined by this BIP. This way the user must only store their seed phrase, and knowledge that they have coins stored using this BIP standard. The user doesn't need to remember or store any dates.
 This standard is already implemented and deployed in JoinMarket. As most changes would require a protocol change of a live system, there is limited scope for changing this standard in review. This BIP is more about documenting something which already exists, warts and all.
 == Specifications ==
 This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] master private key. It also defines the format of the certificate that can be signed by the deterministic address key.
 === Public key derivation ===
 To derive a public key from the root account, this BIP uses a similar account-structure as defined in BIP [[bip-0084.mediawiki|44]] but with <tt>change</tt> set to <tt>2</tt>.
 <pre>
 m / 84' / 0' / 0' / 2 / index
 </pre>
 A key derived with this derivation path pattern will be referred to as <tt>derived_key</tt> further
 in this document.
 For <tt>index</tt>, addresses are numbered from 0 in a sequentially increasing manner with a fixed upper bound: The index only goes up to <tt>959</tt> inclusive. Only 960 addresses can be derived for a given BIP32 master key. Furthermore there is no concept of a gap limit, instead wallets must always generate all 960 addresses and check for all of them if they have a balance and history.
 === Timelock derivation ===
 The timelock used in the time-locked address is derived from the <tt>index</tt>. The timelock is a unix time. It is always at the start of the first second at the beginning of the month (see [[#Test vectors|Test vectors]]). The <tt>index</tt> counts upwards the months from January 2020, ending in December 2099. At 12 months per year for 80 years this totals 960 timelocks. Note that care must be taken with the year 2038 problem on 32-bit systems.
 <pre>
 year = 2020 + index // 12
 month = 1 + index % 12
 </pre>
 === Address derivation ===
 To derive the address from the above calculated public key and timelock, we create a <tt>witness script</tt> which locks the funds until the <tt>timelock</tt>, and then checks the signature of the <tt>derived_key</tt>. The <tt>witness script</tt> is hashed with SHA256 to produce a 32-byte hash value that forms the <tt>witness program</tt> in the output script of the P2WSH address.
    witnessScript: <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP <derived_key> OP_CHECKSIG
    witness:      <signature> <witnessScript>
    scriptSig:    (empty)
    scriptPubKey: 0 <32-byte-hash>
                  (0x0020{32-byte-hash})
 === Message signing ===
 In order to support signing of certificates, implementors should support signing ASCII messages.
 The certificate message is defined as `"fidelity-bond-cert" || "|" || cert_pubkey || "|" || cert_expiry`.
 The certificate expiry `cert_expiry` is the number of the 2016-block period after which the certificate is no longer valid. For example, if `cert_expiry` is 330 then the certificate will become invalid after block height 665280 (:=330x2016). The purpose of the expiry parameter is so that in case the certificate keypair is compromised, the attacker can only impersonate the fidelity bond for a limited amount of time.
 A certificate message can be created by another application external to this standard. It is then prepended with the string `0x18 || "Bitcoin Signed Message:\n"` and a byte denoting the length of the certificate message. The whole thing is then signed with the private key of the <tt>derived_key</tt>. This part is identical to the "Sign Message" function which many wallets already implement.
 Almost all wallets implementing this standard can use their already-existing "Sign Message" function to sign the certificate message. As the certificate message itself is always an ASCII string, the wallet may not need to specially implement this section at all but just rely on users copypasting their certificate message into the already-existing "Sign Message" user interface. This works as long as the wallet knows how to use the private key of the timelocked address for signing messages.
 It is most important for wallet implementations of this standard to support creating the certificate signature. Verifying the certificate signature is less important.
 == Test vectors ==
 <pre>
 mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
 rootpriv = xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu
 rootpub  = xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8
 // First timelocked address = m/84'/0'/0'/2/0
 derived private_key = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d
 derived public_key  = 02a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011
 unix locktime       = 1577836800
 string locktime     = 2020-01-01 00:00:00
 redeemscript        = 0400e10b5eb1752102a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011ac
 scriptPubKey        = 0020bdee9515359fc9df912318523b4cd22f1c0b5410232dc943be73f9f4f07e39ad
 address             = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84
 // Test certificate using the first timelocked address
 // Note that as signatures contains a random nonce, it might not be exactly the same when your code generates it
 // p2pkh address is the p2pkh address corresponding to the derived public key, it can be used to verify the message
 //  signature in any wallet that supports Verify Message.
 // As mentioned before, it is more important for implementors of this standard to support signing such messages, not verifying them
 message       = fidelity-bond-cert|020000000000000000000000000000000000000000000000000000000000000001|375
 address       = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84
 p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6
 signature     = H2b/90XcKnIU/D1nSCPhk8OcxrHebMCr4Ok2d2yDnbKDTSThNsNKA64CT4v2kt+xA1JmGRG/dMnUUH1kKqCVSHo=
 // 2nd timelocked address = m/84'/0'/0'/2/1
 derived private_key = KxctaFBzetyc9KXeUr6jxESCZiCEXRuwnQMw7h7hroP6MqnWN6Pf
 derived public_key  = 02599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002d
 unix locktime       = 1580515200
 string locktime     = 2020-02-01 00:00:00
 redeemscript        = 0480bf345eb1752102599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002dac
 scriptPubKey        = 0020b8f898643991608524ed04e0c6779f632a57f1ffa3a3a306cd81432c5533e9ae
 address             = bc1qhrufsepej9sg2f8dqnsvvaulvv490u0l5w36xpkds9pjc4fnaxhq7pcm4h
 // timelocked address after the year 2038 = m/84'/0'/0'/2/240
 derived private_key = L3SYqae23ZoDDcyEA8rRBK83h1MDqxaDG57imMc9FUx1J8o9anQe
 derived public_key  = 03ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226
 unix locktime       = 2208988800
 string locktime     = 2040-01-01 00:00:00
 redeemscript        = 05807eaa8300b1752103ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226ac
 scriptPubKey        = 0020e7de0ad2720ae1d6cc9b6ad91af57eb74646762cf594c91c18f6d5e7a873635a
 address             = bc1qul0q45njptsadnymdtv34at7karyva3v7k2vj8qc7m2702rnvddq0z20u5
 // last timelocked address = m/84'/0'/0'/2/959
 derived private_key = L5Z9DDMnj5RZMyyPiQLCvN48Xt7GGmev6cjvJXD8uz5EqiY8trNJ
 derived public_key  = 0308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3
 unix locktime       = 4099766400
 string locktime     = 2099-12-01 00:00:00
 redeemscript        = 0580785df400b175210308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3ac
 scriptPubKey        = 0020803268e042008737cf439748cbb5a4449e311da9aa64ae3ac56d84d059654f85
 address             = bc1qsqex3czzqzrn0n6rjayvhddygj0rz8df4fj2uwk9dkzdqkt9f7zs5c493u
 // Test certificate and endpoint signing using the first timelocked address = m/84'/0'/0'/2/0 (see above)
 bond private_key          = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d
 bond p2pkh address        = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6
 certificate private_key   = KyZpNDKnfs94vbrwhJneDi77V6jF64PWPF8x5cdJb8ifgg2DUc9d
 certificate public_key    = 0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c
 certificate p2pkh address = 1JaUQDVNRdhfNsVncGkXedaPSM5Gc54Hso
 certificate message       = fidelity-bond-cert|0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c|375
 certificate signature     = INOP3cB9UW7F1e1Aglj8rI9QhnyxmgWDEPt+nOMvl7hJJne7rH/KCNDYvLiqNuB9qWaWUojutjRsgPJrvyDQ+0Y=
 // example endpoint signing two IRC nicknames (used in JoinMarket)
 endpoint message          = J54LS6YyJPoseqFS|J55VZ6U6ZyFDNeuv
 endpoint signature        = H18WE4MugDNoWZIf9jU0njhQptdUyBDUf7lToG9bpMKmeJK0lOoABaDs5bKnohSuZ0e9gnSco5OL9lXdKU7gP5E=
 </pre>
 Code generating these test vectors can be found here: https://github.com/chris-belcher/timelocked-addresses-fidelity-bond-bip-testvectors
 == Reference ==
 * [[https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/|Design for improving JoinMarket's resistance to sybil attacks using fidelity bonds]]
 * [[https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/fidelity-bonds.md|JoinMarket fidelity bonds doc page]]
 * [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]]
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
 * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
 * [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]]
 * [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]
 * [[bip-0086.mediawiki|BIP86 - Key Derivation for Single Key P2TR Outputs]]
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@ -17,7 +17,7 @@ RECENT CHANGES:
 ==Status==
-This BIP can be be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process.
+This BIP can be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process.
 The Open Bitcoin Privacy Project RFC repo should be consulted for specifications related to version 3 or higher payment codes: https://github.com/OpenBitcoinPrivacyProject/rfc
@ -275,7 +275,7 @@ Normal operation of a payment code-enabled wallet can be performed by an SPV cli
 Recovering a wallet from a seed, however, does require access to a fully-indexed blockchain.
-The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queriable blockchain explorer.
+The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queryable blockchain explorer.
 When querying a public blockchain explorer, wallets SHOULD connect to the explorer through Tor (or equivalent) and SHOULD avoid grouping queries in a manner that associates ephemeral addresses with each other.
@ -350,12 +350,12 @@ Version 2 payment codes behave identifically to version 1 payment codes, except
 ====Definitions====
-* Notification change output: the change output from a notification transaction which which resides in the sender's wallet, but can be automatically located by the intended recipient
+* Notification change output: the change output from a notification transaction which resides in the sender's wallet, but can be automatically located by the intended recipient
 * Payment code identifier: a 33 byte representation of a payment code constructed by prepending 0x02 to the SHA256 hash of the binary serialization of the payment code
 ====Notification Transaction====
-Note: this procedure is used if Bob uses a version 2 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification.
+Note: this procedure is used if Bob uses a version 2 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification.
 # Construct a notification transaction as per the version 1 instructions, except do not create the output to Bob's notification address
 # Create a notification change address as follows:
--- a/bip-0049.mediawiki
+++ b/bip-0049.mediawiki
@ -92,10 +92,10 @@ This BIP is not backwards compatible by design as described under [[#considerati
  // Account 0, first receiving private key = m/49'/1'/0'/0/0
  account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ
  account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8
-  account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
+  account0recvPublicKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
  // Address derivation
-  keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
+  keyhash = HASH160(account0recvPublicKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
  scriptSig = <0 <keyhash>> = 0x001438971f73930f6c141d977ac4fd4a727c854935b3
  addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742
--- a/bip-0052.mediawiki
+++ b/bip-0052.mediawiki
@ -25,7 +25,7 @@ Bitcoin network cannot profitably mine Bitcoin even if they have the capital to
 invest in mining hardware. From a practical perspective, Bitcoin adoption by
 companies like Tesla (which recently rescinded its acceptance of Bitcoin as
 payment) has been hampered by its massive energy consumption and perceived
-environmental impact. 
+environmental impact.
 <img src="bip-0052/btc_energy-small.png"></img>
@ -137,7 +137,7 @@ x1 <- keccak(input)
 x2 <- reshape(x1, 64)
 // Perform a matrix-vector multiplication.
-// The result is 64-vector of 14-bit unsigned. 
+// The result is 64-vector of 14-bit unsigned.
 x3 <- vector_matrix_mult(x2, M)
 // Truncate all values to 4 most significant bits.
--- a/bip-0064.mediawiki
+++ b/bip-0064.mediawiki
@ -86,7 +86,7 @@ If the requesting client is looking up outputs for a signed transaction that the
 client can partly verify the returned output by running the input scripts with it. Currently this
 verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also
 allow the value to be checked in this way. It does not show that the output is really unspent or was
-ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey 
+ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey
 should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE.
 If the requesting client has a mapping of chain heights to block hashes in the best chain e.g.
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@ -170,7 +170,7 @@ Proving the sacrifice of some limited resource is a common technique in a
 variety of cryptographic protocols. Proving sacrifices of coins to mining fees
 has been proposed as a ''universal public good'' to which the sacrifice could
 be directed, rather than simply destroying the coins. However doing so is
-non-trivial, and even the best existing technqiue - announce-commit sacrifices
+non-trivial, and even the best existing technique - announce-commit sacrifices
 - could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to
 create outputs that are provably spendable by anyone (thus to mining fees
 assuming miners behave optimally and rationally) but only at a time
@ -205,19 +205,19 @@ transaction output ''can'' be spent.
 Refer to the reference implementation, reproduced below, for the precise
 semantics and detailed rationale for those semantics.
-    
+
    case OP_NOP2:
    {
        // CHECKLOCKTIMEVERIFY
        //
        // (nLockTime -- nLockTime )
-    
+
        if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY))
            break; // not enabled; treat as a NOP
-    
+
        if (stack.size() < 1)
            return false;
-    
+
        // Note that elsewhere numeric opcodes are limited to
        // operands in the range -2**31+1 to 2**31-1, however it is
        // legal for opcodes to produce results exceeding that
@ -233,13 +233,13 @@ semantics and detailed rationale for those semantics.
        // to 5-byte bignums, which are good until 2**32-1, the
        // same limit as the nLockTime field itself.
        const CScriptNum nLockTime(stacktop(-1), 5);
-    
+
        // In the rare event that the argument may be < 0 due to
        // some arithmetic being done first, you can always use
        // 0 MAX CHECKLOCKTIMEVERIFY.
        if (nLockTime < 0)
            return false;
-    
+
        // There are two types of nLockTime: lock-by-blockheight
        // and lock-by-blocktime, distinguished by whether
        // nLockTime < LOCKTIME_THRESHOLD.
@ -252,12 +252,12 @@ semantics and detailed rationale for those semantics.
              (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
             ))
            return false;
-    
+
        // Now that we know we're comparing apples-to-apples, the
        // comparison is a simple numeric one.
        if (nLockTime > (int64_t)txTo.nLockTime)
            return false;
-    
+
        // Finally the nLockTime feature can be disabled and thus
        // CHECKLOCKTIMEVERIFY bypassed if every txin has been
        // finalized by setting nSequence to maxint. The
@ -270,9 +270,9 @@ semantics and detailed rationale for those semantics.
        // required to prove correct CHECKLOCKTIMEVERIFY execution.
        if (txTo.vin[nIn].IsFinal())
            return false;
-    
+
        break;
-    
+
    }
 https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4
--- a/bip-0066.mediawiki
+++ b/bip-0066.mediawiki
@ -75,7 +75,7 @@ bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {
    // Verify that the length of the signature matches the sum of the length
    // of the elements.
    if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
- 
+
    // Check whether the R element is an integer.
    if (sig[2] != 0x02) return false;
@ -140,7 +140,7 @@ An implementation for the reference client is available at https://github.com/bi
 ==Acknowledgements==
-This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well. 
+This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
 ==Disclosures==
--- a/bip-0067.mediawiki
+++ b/bip-0067.mediawiki
@ -19,7 +19,7 @@ This BIP describes a method to deterministically generate multi-signature pay-to
 ==Motivation==
-Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts. 
+Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.
 Multi-signature pay-to-script-hash transactions are defined in BIP-0016<ref>[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP-0016]</ref>. The redeem script does not require a particular ordering or encoding for public keys.  This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address.  Adhering to an ordering and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address.
@ -27,31 +27,31 @@ By adopting a sorting and encoding standard, compliant wallets will always produ
 While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this.
-Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.  
+Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.
 This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider.
 ==Specification==
 For a set of public keys, ensure that they have been received in compressed form:
-    
+
    022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
-    03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 
+    03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
    021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
- 
+
-Sort them lexicographically according to their binary representation: 
+Sort them lexicographically according to their binary representation:
-    
+
    021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
    022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
    03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
-..before using the resulting list of keys in a standard multisig redeem script:  
+..before using the resulting list of keys in a standard multisig redeem script:
-    
+
    OP_2 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 OP_3 OP_CHECKMULTISIG
 Hash the redeem script according to BIP-0016 to get the P2SH address.
-    
+
    3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
-    
+
 ==Compatibility==
 * Uncompressed keys are incompatible with this specification. A compatible implementation should not automatically compress keys.  Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation.
 * P2SH addresses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network.  Also, it would cause a hard fork.
@ -75,11 +75,11 @@ Vector 1
 ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
 Vector 2 (Already sorted, no action required)
-* List: 
+* List:
 ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
-* Sorted: 
+* Sorted:
 ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
@ -89,12 +89,12 @@ Vector 2 (Already sorted, no action required)
 ** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
 Vector 3:
-* List:    
+* List:
 ** 030000000000000000000000000000000000004141414141414141414141414141
 ** 020000000000000000000000000000000000004141414141414141414141414141
 ** 020000000000000000000000000000000000004141414141414141414141414140
 ** 030000000000000000000000000000000000004141414141414141414141414140
-* Sorted: 
+* Sorted:
 ** 020000000000000000000000000000000000004141414141414141414141414140
 ** 020000000000000000000000000000000000004141414141414141414141414141
 ** 030000000000000000000000000000000000004141414141414141414141414140
@ -105,11 +105,11 @@ Vector 3:
 ** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
 Vector 4: (from bitcore)
-* List: 
+* List:
 ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
-** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 
+** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
 ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
-* Sorted: 
+* Sorted:
 ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
 ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
 ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
@ -119,13 +119,13 @@ Vector 4: (from bitcore)
 ** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
 ==Acknowledgements==
-The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP. 
+The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP.
-==Usage & Implementations== 
+==Usage & Implementations==
-* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets 
+* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets
-* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]] 
+* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]]
 * [[https://github.com/haskoin/haskoin-core/blob/b41b1deb0989334a7ead6fc993fb8b02f0c00810/haskoin-core/Network/Haskoin/Script/Parser.hs#L112-L122|Haskoin]] - Bitcoin implementation in Haskell
-* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]] 
+* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]]
 * [[https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]]
 == References ==
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@ -33,7 +33,7 @@ If bit (1 << 31) of the sequence number is set, then no consensus meaning is app
 If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
-The sequence number encoding is interpreted as follows: 
+The sequence number encoding is interpreted as follows:
 Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
@ -65,7 +65,7 @@ enum {
    /* Interpret sequence numbers as relative lock-time constraints. */
    LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
 };
-    
+
 /* Setting nSequence to this value for every input in a transaction
 * disables nLockTime. */
 static const uint32_t SEQUENCE_FINAL = 0xffffffff;
@ -245,7 +245,7 @@ The most efficient way to calculate sequence number from relative lock-time is w
    // 0 <= nHeight < 65,535 blocks (1.25 years)
    nSequence = nHeight;
    nHeight = nSequence & 0x0000ffff;
-    
+
    // 0 <= nTime < 33,554,431 seconds (1.06 years)
    nSequence = (1 << 22) | (nTime >> 9);
    nTime = (nSequence & 0x0000ffff) << 9;
--- a/bip-0072.mediawiki
+++ b/bip-0072.mediawiki
@ -69,4 +69,4 @@ bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
 ==References==
-[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 
+[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@ -18,11 +18,11 @@
 This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
-# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. 
+# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with.
 # It encrypts the PaymentRequest that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details.
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
 ==Copyright==
@ -217,9 +217,9 @@ message EncryptedProtocolMessage {
 |}
 ==Payment Protocol Process with InvoiceRequests==
-The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below. 
+The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below.
 <br/><br/>
-All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]]. 
+All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]].
 <br/><br/>
 All Payment Protocol messages SHOULD be communicated using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#InvoiceRequest|InvoiceRequest]] MAY be communicated using the [[#ProtocolMessage|ProtocolMessage]] if the receiver's public key is unknown.
 <br/><br/>
@ -257,14 +257,14 @@ When communicated via '''HTTP''', the listed messages MUST be transmitted via TL
 ===Payment Protocol Status Communication===
-Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately. 
+Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately.
 <br/><br/>
 The status_message value SHOULD be set with a human readable explanation of the status code.
 ====Payment Protocol Status Codes====
 {| class="wikitable"
 ! Status Code !! Description
-|- 
+|-
 | 1     || OK
 |-
 | 2     || Cancel
@ -324,7 +324,7 @@ For the following we assume the Sender already knows the Receiver's public key,
 ** Set '''signature''' value to the computed signature
 ===InvoiceRequest Validation===
-* Validate '''sender_public_key''' is a valid EC public key 
+* Validate '''sender_public_key''' is a valid EC public key
 * Validate '''notification_url''', if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).
 * If '''pki_type''' is None, [[#InvoiceRequest|InvoiceRequest]] is VALID
 * If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#InvoiceRequest|InvoiceRequest]] where signature is set to "", [[#InvoiceRequest|InvoiceRequest]] is VALID
@ -366,7 +366,7 @@ For the following we assume the Sender already knows the Receiver's public key,
 The 16 byte authentication tag resulting from the AES-GCM encrypt operation MUST be prefixed to the returned ciphertext. The decrypt operation will use the first 16 bytes of the ciphertext as the GCM authentication tag and the remainder of the ciphertext as the ciphertext in the decrypt operation.
 ====AES-256 GCM Additional Authenticated Data====
-When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated. 
+When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated.
 ===Initial Public Key Retrieval for InvoiceRequest Encryption===
 Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption via [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:
@ -387,7 +387,7 @@ Clients SHOULD keep in mind Receivers can broadcast a transaction without return
 ==Public Key & Signature Encoding==
 * All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
-* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed. 
+* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed.
 * All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
 * All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1.
--- a/bip-0078.mediawiki
+++ b/bip-0078.mediawiki
@ -95,7 +95,7 @@ The payjoin proposal PSBT is sent in the HTTP response body, base64 serialized w
 To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header <code>Access-Control-Allow-Origin: *</code>.
-The sender must ensure that the url refers to a scheme or protocol using authenticated encryption, for example TLS with certificate validation, or a .onion link to a hidden service whose public key identifier has already been communicated via a TLS connection. Senders SHOULD NOT accept a url representing an unencrypted or unauthenticated connection.
+The sender must ensure that the URL refers to a scheme or protocol using authenticated encryption, for example TLS with certificate validation, or a .onion link to a hidden service whose public key identifier has already been communicated via a TLS connection. Senders SHOULD NOT accept a URL representing an unencrypted or unauthenticated connection.
 The original PSBT MUST:
 * Have all the <code>witnessUTXO</code> or <code>nonWitnessUTXO</code> information filled in.
@ -111,7 +111,7 @@ The original PSBT SHOULD NOT:
 The payjoin proposal MUST:
 * Use all the inputs from the original PSBT.
-* Use all the outputs which do not belongs to the receiver from the original PSBT.
+* Use all the outputs which do not belong to the receiver from the original PSBT.
 * Only finalize the inputs added by the receiver. (Referred later as <code>additional inputs</code>)
 * Only fill the <code>witnessUTXO</code> or <code>nonWitnessUTXO</code> for the additional inputs.
@ -195,10 +195,10 @@ The well-known error codes are:
 |The receiver rejected the original PSBT.
 |}
-The receiver is allowed to return implementation specific errors which may assist the sender to diagnose any issue.
+The receiver is allowed to return implementation-specific errors which may assist the sender to diagnose any issue.
 However, it is important that error codes that are not well-known and that the message do not appear on the sender's software user interface.
-Such error codes or messages could be used maliciously to phish a non technical user.
+Such error codes or messages could be used maliciously to phish a non-technical user.
 Instead those errors or messages can only appear in debug logs.
 It is advised to hard code the description of the well known error codes into the sender's software.
@ -221,7 +221,7 @@ To prevent this, the sender can agree to pay more fee so the receiver make sure
 * The sender's transaction is time sensitive.
-When a sender pick a specific fee rate, the sender expects the transaction to be confirmed after a specific amount of time. But if the receiver adds an input without bumping the fee of the transaction, the payjoin transaction fee rate will be lower, and thus, longer to confirm.
+When a sender picks a specific fee rate, the sender expects the transaction to be confirmed after a specific amount of time. But if the receiver adds an input without bumping the fee of the transaction, the payjoin transaction fee rate will be lower, and thus, longer to confirm.
 Our recommendation for <code>maxadditionalfeecontribution=</code> is <code>originalPSBTFeeRate * 110</code>.
@ -232,8 +232,8 @@ The receiver needs to do some check on the original PSBT before proceeding:
 * Non-interactive receivers (like a payment processor) need to check that the original PSBT is broadcastable. <code>*</code>
 * If the sender included inputs in the original PSBT owned by the receiver, the receiver must either return error <code>original-psbt-rejected</code> or make sure they do not sign those inputs in the payjoin proposal.
 * Make sure that the inputs included in the original transaction have never been seen before.
-** This prevent [[#probing-attack|probing attacks]].
+** This prevents [[#probing-attack|probing attacks]].
-** This prevent reentrant payjoin, where a sender attempts to use payjoin transaction as a new original transaction for a new payjoin.
+** This prevents reentrant payjoin, where a sender attempts to use payjoin transaction as a new original transaction for a new payjoin.
 <code>*</code>: Interactive receivers are not required to validate the original PSBT because they are not exposed to [[#probing-attack|probing attacks]].
@ -245,25 +245,24 @@ The sender should check the payjoin proposal before signing it to prevent a mali
 * If the receiver's BIP21 signalled <code>pjos=0</code>, disable payment output substitution.
 * Verify that the transaction version, and the nLockTime are unchanged.
 * Check that the sender's inputs' sequence numbers are unchanged.
-* For each inputs in the proposal:
+* For each input in the proposal:
-** Verify that no keypaths is in the PSBT input
+** Verify that no keypaths are in the PSBT input
 ** Verify that no partial signature has been filled
-** If it is one of the sender's input
+** If it is one of the sender's inputs:
 *** Verify that input's sequence is unchanged.
 *** Verify the PSBT input is not finalized
-*** Verify that <code>non_witness_utxo</code> and <code>witness_utxo</code> are not specified.
+** If it is one of the receiver's inputs:
 ** If it is one of the receiver's input
 *** Verify the PSBT input is finalized
 *** Verify that <code>non_witness_utxo</code> or <code>witness_utxo</code> are filled in.
-** Verify that the payjoin proposal did not introduced mixed input's sequence.
+** Verify that the payjoin proposal inputs all specify the same sequence value.
 ** Verify that all of sender's inputs from the original PSBT are in the proposal.
-* For each outputs in the proposal:
+* For each output in the proposal:
-** Verify that no keypaths is in the PSBT output
+** Verify that no keypaths are in the PSBT output
 ** If the output is the [[#fee-output|fee output]]:
 *** The amount that was subtracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>.
-*** Make sure the actual contribution is only paying fee: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT.
+*** Make sure the actual contribution is only going towards fees: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT.
-*** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section)
+*** Make sure the actual contribution is only paying for fees incurred by additional inputs: <code>actual contribution</code> is less than or equal to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section)
-** If the output is the payment output and payment output substitution is allowed.
+** If the output is the payment output and payment output substitution is allowed,
 *** Do not make any check
 ** Else
 *** Make sure the output's value did not decrease.
@ -274,8 +273,8 @@ The sender must be careful to only sign the inputs that were present in the orig
 Note:
 * The sender must allow the receiver to add/remove or modify the receiver's own outputs. (if payment output substitution is disabled, the receiver's outputs must not be removed or decreased in value)
-* The sender should allow the receiver to not add any inputs. This is useful for the receiver to change the paymout output scriptPubKey type.
+* The sender should allow the receiver to not add any inputs. This is useful for the receiver to change the payment output scriptPubKey type.
-* If no input have been added, the sender's wallet implementation should accept the payjoin proposal, but not mark the transaction as an actual payjoin in the user interface.
+* If the receiver added no inputs, the sender's wallet implementation should accept the payjoin proposal, but not mark the transaction as an actual payjoin in the user interface.
 Our method of checking the fee allows the receiver and the sender to batch payments in the payjoin transaction.
 It also allows the receiver to pay the fee for batching adding his own outputs.
@ -331,7 +330,7 @@ On top of this the receiver can poison analysis by randomly faking a round amoun
 ===<span id="output-substitution"></span>Payment output substitution===
-Unless disallowed by sender explicitly via `disableoutputsubstitution=true` or by the BIP21 url via query parameter the `pjos=0`, the receiver is free to decrease the amount, or change the scriptPubKey output paying to himself.
+Unless disallowed by the sender explicitly via <code>disableoutputsubstitution=true</code> or by the BIP21 URL via the query parameter <code>pjos=0</code>, the receiver is free to decrease the amount or change the scriptPubKey output paying to himself.
 Note that if payment output substitution is disallowed, the reveiver can still increase the amount of the output. (See [[#reference-impl|the reference implementation]])
 For example, if the sender's scriptPubKey type is P2WPKH while the receiver's payment output in the original PSBT is P2SH, then the receiver can substitute the payment output to be P2WPKH to match the sender's scriptPubKey type.
@ -345,7 +344,7 @@ A compromised payjoin server could steal the hot wallet outputs of the receiver,
 ===Impacted heuristics===
-Our proposal of payjoin is breaking the following blockchain heuristics:
+Our proposal of payjoin breaks the following blockchain heuristics:
 * Common inputs heuristics.
@ -395,7 +394,7 @@ With payjoin, the maximum amount of money that can be lost is equal to two payme
 ==<span id="reference-impl"></span>Reference sender's implementation==
 Here is pseudo code of a sender implementation.
-<code>RequestPayjoin</code> takes the bip21 URI of the payment, the wallet and the <code>signedPSBT</code>.
+<code>RequestPayjoin</code> takes the BIP21 URI of the payment, the wallet and the <code>signedPSBT</code>.
 The <code>signedPSBT</code> represents a PSBT which has been fully signed, but not yet finalized.
 We then prepare <code>originalPSBT</code> from the <code>signedPSBT</code> via the <code>CreateOriginalPSBT</code> function and get back the <code>proposal</code>.
@ -483,9 +482,6 @@ public async Task<PSBT> RequestPayjoin(
            // Verify the PSBT input is not finalized
            if (proposedPSBTInput.IsFinalized())
                throw new PayjoinSenderException("The receiver finalized one of our inputs");
            // Verify that <code>non_witness_utxo</code> and <code>witness_utxo</code> are not specified.
            if (proposedPSBTInput.NonWitnessUtxo != null || proposedPSBTInput.WitnessUtxo != null)
                throw new PayjoinSenderException("The receiver added non_witness_utxo or witness_utxo to one of our inputs");
            sequences.Add(proposedTxIn.Sequence);
            // Fill up the info from the original PSBT input so we can sign and get fees.
@ -628,7 +624,7 @@ A successful exchange with:
 <pre>cHNidP8BAHMCAAAAAY8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////AtyVuAUAAAAAF6kUHehJ8GnSdBUOOv6ujXLrWmsJRDCHgIQeAAAAAAAXqRR3QJbbz0hnQ8IvQ0fptGn+votneofTAAAAAAEBIKgb1wUAAAAAF6kU3k4ekGHKWRNbA1rV5tR5kEVDVNCHAQcXFgAUx4pFclNVgo1WWAdN1SYNX8tphTABCGsCRzBEAiB8Q+A6dep+Rz92vhy26lT0AjZn4PRLi8Bf9qoB/CMk0wIgP/Rj2PWZ3gEjUkTlhDRNAQ0gXwTO7t9n+V14pZ6oljUBIQMVmsAaoNWHVMS02LfTSe0e388LNitPa1UQZyOihY+FFgABABYAFEb2Giu6c4KO5YW0pfw3lGp9jMUUAAA=</pre>
 <code>payjoin proposal</code>
-<pre>cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAAEBIICEHgAAAAAAF6kUyPLL+cphRyyI5GTUazV0hF2R2NWHAQcXFgAUX4BmVeWSTJIEwtUb5TlPS/ntohABCGsCRzBEAiBnu3tA3yWlT0WBClsXXS9j69Bt+waCs9JcjWtNjtv7VgIge2VYAaBeLPDB6HGFlpqOENXMldsJezF9Gs5amvDQRDQBIQJl1jz1tBt8hNx2owTm+4Du4isx0pmdKNMNIjjaMHFfrQAAAA==</pre>
+<pre>cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAQEgqBvXBQAAAAAXqRTeTh6QYcpZE1sDWtXm1HmQRUNU0IcAAQEggIQeAAAAAAAXqRTI8sv5ymFHLIjkZNRrNXSEXZHY1YcBBxcWABRfgGZV5ZJMkgTC1RvlOU9L+e2iEAEIawJHMEQCIGe7e0DfJaVPRYEKWxddL2Pr0G37BoKz0lyNa02O2/tWAiB7ZVgBoF4s8MHocYWWmo4Q1cyV2wl7MX0azlqa8NBENAEhAmXWPPW0G3yE3HajBOb7gO7iKzHSmZ0o0w0iONowcV+tAAAA</pre>
 <code>payjoin proposal filled with sender's information</code>
 <pre>cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAQEgqBvXBQAAAAAXqRTeTh6QYcpZE1sDWtXm1HmQRUNU0IcBBBYAFMeKRXJTVYKNVlgHTdUmDV/LaYUwIgYDFZrAGqDVh1TEtNi300ntHt/PCzYrT2tVEGcjooWPhRYYSFzWUDEAAIABAACAAAAAgAEAAAAAAAAAAAEBIICEHgAAAAAAF6kUyPLL+cphRyyI5GTUazV0hF2R2NWHAQcXFgAUX4BmVeWSTJIEwtUb5TlPS/ntohABCGsCRzBEAiBnu3tA3yWlT0WBClsXXS9j69Bt+waCs9JcjWtNjtv7VgIge2VYAaBeLPDB6HGFlpqOENXMldsJezF9Gs5amvDQRDQBIQJl1jz1tBt8hNx2owTm+4Du4isx0pmdKNMNIjjaMHFfrQABABYAFEb2Giu6c4KO5YW0pfw3lGp9jMUUIgICygvBWB5prpfx61y1HDAwo37kYP3YRJBvAjtunBAur3wYSFzWUDEAAIABAACAAAAAgAEAAAABAAAAAAA=</pre>
@ -643,7 +639,7 @@ A successful exchange with:
 ==Backward compatibility==
-The receivers are advertising payjoin capabilities through [[bip-0021.mediawiki|BIP21's URI Scheme]].
+The receivers advertise payjoin capabilities through [[bip-0021.mediawiki|BIP21's URI Scheme]].
 Senders not supporting payjoin will just ignore the <code>pj</code> variable and thus, will proceed to normal payment.
--- a/bip-0079.mediawiki
+++ b/bip-0079.mediawiki
@ -84,7 +84,7 @@ After adding inputs to the transaction, the receiver generally will want to adju
 === Returning the partial transaction ===
-The receiver must sign all contributed inputs in the partial transaction. The partial transaction should also remove all witnesses from the the original template transaction as they are no longer valid, and need to be recalculated by the sender. The receiver returns the partial transaction as a binary-encoded HTTP response with a status code of 200. To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header "Access-Control-Allow-Origin: *"
+The receiver must sign all contributed inputs in the partial transaction. The partial transaction should also remove all witnesses from the original template transaction as they are no longer valid, and need to be recalculated by the sender. The receiver returns the partial transaction as a binary-encoded HTTP response with a status code of 200. To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header "Access-Control-Allow-Origin: *"
 === Sender Validation ===
--- a/bip-0083.mediawiki
+++ b/bip-0083.mediawiki
@ -83,7 +83,7 @@ We can continue creating subaccounts indefinitely using this scheme.
 In order to create a bidirectional payment channel, it is necessary that previous commitments be revokable. In order to revoke previous commitments, each party reveals a secret to the other that would allow them to steal the funds in the channel if a transaction for a previous commitment is inserted into the blockchain.
-By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children. 
+By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children.
 ==References==
--- a/bip-0084.mediawiki
+++ b/bip-0084.mediawiki
@ -61,7 +61,7 @@ Additional registered version bytes are listed in [[https://github.com/satoshila
 ==Backwards Compatibility==
-This BIP is not backwards compatible by design as described under [#considerations]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong.
+This BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong.
 ==Test vectors==
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@ -3,9 +3,10 @@
  Layer: Applications
  Title: Deterministic Entropy From BIP32 Keychains
  Author: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
          Aneesh Karve <dowsing.seaport0d@icloud.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0085
-  Status: Draft
+  Status: Final
  Type: Informational
  Created: 2020-03-20
  License: BSD-2-Clause
@ -14,15 +15,19 @@
 ==Abstract==
-''"One Seed to rule them all,''
+''"One Seed to rule them all,''<br>
-''One Key to find them,''
+''One Key to find them,''<br>
-''One Path to bring them all,''
+''One Path to bring them all,''<br>
 ''And in cryptography bind them."''
 It is not possible to maintain one single (mnemonic) seed backup for all keychains used across various wallets because there are a variety of incompatible standards. Sharing of seeds across multiple wallets is not desirable for security reasons. Physical storage of multiple seeds is difficult depending on the security and redundancy required.
 As HD keychains are essentially derived from initial entropy, this proposal provides a way to derive entropy from the keychain which can be fed into whatever method a wallet uses to derive the initial mnemonic seed or root key.
 ==Copyright==
 This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
 ==Definitions==
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
@ -33,13 +38,16 @@ The terminology related to keychains used in the wild varies widely, for example
 # '''BIP39 mnemonic''' is the mnemonic phrase that is calculated from the entropy used before hashing of the mnemonic in BIP39.
 # '''BIP39 seed''' is the result of hashing the BIP39 mnemonic seed.
 When in doubt, assume big endian byte serialization, such that the leftmost
 byte is the most significant.
 ==Motivation==
-Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
+Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human-friendly serialization of the BIP32 root key (or BIP32 extended keys in general), which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem, but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed, which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
-Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
+Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenario is particularly satisfactory for security reasons. For example, some wallets may be inherently less secure, like hot wallets on smartphones, JoinMarket servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding keys is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
-There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets like Electrum use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies like Monero also use an entirely different mnemonic scheme.
+There is an added complication with wallets that implement other standards, or no standards at all. The Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets, like Electrum, use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies, like Monero, use an entirely different mnemonic scheme.
 Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according to the specific application standard of the target wallet. We can use a BIP44-like categorization to ensure uniform derivation according to the target application type.
@ -47,9 +55,13 @@ Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" t
 We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39).
-For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest.
+For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>
 <ref name="hmac-sha512">
 The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromised. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur.
 </ref>.
 The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation, and truncate the rest.
-The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].
+The HMAC-SHA512 function is specified in [https://tools.ietf.org/html/rfc4231 RFC 4231].
 ===Test vectors===
@ -78,7 +90,7 @@ BIP85-DRNG-SHAKE256 is a deterministic random number generator for cryptographic
 RSA key generation is an example of a function that requires orders of magnitude more than 64 bytes of random input. Further, it is not possible to precalculate the amount of random input required until the function has completed.
    drng_reader = BIP85DRNG.new(bip85_entropy)
-    rsa_key = RSA.generate_key(4096, drng_reader.read())
+    rsa_key = RSA.generate_key(4096, drng_reader.read)
 ===Test Vectors===
 INPUT:
@ -91,28 +103,13 @@ OUTPUT
 * DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111
 ==Reference Implementation==
 * Python library implementation: [https://github.com/ethankosakovsky/bip85]
 * JavaScript library implementation: [https://github.com/hoganri/bip85-js]
 ===Other Implementations===
 * JavaScript library implementation: [https://github.com/hoganri/bip85-js]
 * Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39]
 * Ian Coleman's Mnemonic Code Converter: [https://github.com/iancoleman/bip39] and [https://iancoleman.io/bip39/]
 * AirGap Vault: [https://github.com/airgap-it/airgap-vault/commit/d64332fc2f332be622a1229acb27f621e23774d6]
 * btc_hd_wallet: [https://github.com/scgbckbone/btc-hd-wallet]
 ==Applications==
 The Application number defines how entropy will be used post processing. Some basic examples follow:
-Derivation path uses the format <code>m/83696968'/{app_no}'/{index}'</code> where ''{app_no}'' is the path for the application, and ''{index}'' is the index.
+Derivation paths follow the format <code>m/83696968'/{app_no}'/{index}'</code>, where ''{app_no}'' is the path for the application, and ''{index}'' is the index.
 Application numbers should be semantic in some way, such as a BIP number or ASCII character code sequence.
 ===BIP39===
 Application number: 39'
@ -155,6 +152,10 @@ Language Table
 |-
 | Czech
 | 8'
 |-
 | Portuguese
 | 9'
 |-
 |}
 Words Table
@ -168,10 +169,18 @@ Words Table
 | 128 bits
 | 12'
 |-
 | 15 words
 | 160 bits
 | 15'
 |-
 | 18 words
 | 192 bits
 | 18'
 |-
 | 21 words
 | 224 bits
 | 21'
 |-
 | 24 words
 | 256 bits
 | 24'
@ -219,7 +228,16 @@ OUTPUT:
 ===HD-Seed WIF===
 Application number: 2'
-Uses 256 bits[1] of entropy as the secret exponent to derive a private key and encode as a compressed WIF which will be used as the hdseed for Bitcoin Core wallets.
+Uses the most significant 256 bits<ref name="curve-order">
 There is a very small chance that you'll make an invalid
 key that is zero or larger than the order of the curve. If this occurs, software
 should hard fail (forcing users to iterate to the next index). From BIP32:
 <blockquote>
 In case parse<sub>256</sub>(I<sub>L</sub>) ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.)
 </blockquote>
 </ref>
 of entropy as the secret exponent to derive a private key and encode as a compressed
 WIF that will be used as the hdseed for Bitcoin Core wallets.
 Path format is <code>m/83696968'/2'/{index}'</code>
@ -234,7 +252,11 @@ OUTPUT
 ===XPRV===
 Application number: 32'
-Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
+Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes<ref name="curve-order" /> are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
 ''Warning'': The above order reverses the order of BIP32, which takes the first 32 bytes as the private key, and the second 32 bytes as the chain code.
 Applications may support Testnet by emitting TPRV keys if and only if the input root key is a Testnet key.
 Path format is <code>m/83696968'/32'/{index}'</code>
@ -269,7 +291,7 @@ The derivation path format is: <code>m/83696968'/707764'/{pwd_len}'/{index}'</co
 `20 <= pwd_len <= 86`
-[https://datatracker.ietf.org/doc/html/rfc4648 Base64] encode the all 64 bytes of entropy.
+[https://datatracker.ietf.org/doc/html/rfc4648 Base64] encode all 64 bytes of entropy.
 Remove any spaces or new lines inserted by Base64 encoding process. Slice base64 result string
 on index 0 to `pwd_len`. This slice is the password. As `pwd_len` is limited to 86, passwords will not contain padding.
@ -297,7 +319,7 @@ INPUT:
 * PATH: m/83696968'/707764'/21'/0'
 OUTPUT
-* DERIVED ENTROPY=d7ad61d4a76575c5bad773feeb40299490b224e8e5df6c8ad8fe3d0a6eed7b85ead9fef7bcca8160f0ee48dc6e92b311fc71f2146623cc6952c03ce82c7b63fe
+* DERIVED ENTROPY=74a2e87a9ba0cdd549bdd2f9ea880d554c6c355b08ed25088cfa88f3f1c4f74632b652fd4a8f5fda43074c6f6964a3753b08bb5210c8f5e75c07a4c2a20bf6e9
 * DERIVED PWD=dKLoepugzdVJvdL56ogNV
 ===PWD BASE85===
@ -307,7 +329,7 @@ The derivation path format is: <code>m/83696968'/707785'/{pwd_len}'/{index}'</co
 `10 <= pwd_len <= 80`
-Base85 encode the all 64 bytes of entropy.
+Base85 encode all 64 bytes of entropy.
 Remove any spaces or new lines inserted by Base64 encoding process. Slice base85 result string
 on index 0 to `pwd_len`. This slice is the password. `pwd_len` is limited to 80 characters.
@ -327,7 +349,7 @@ Entropy = log2(R ** L)<br>
 |-
 | 30 || 192.0
 |-
-| 20 || 512.0
+| 80 || 512.0
 |}
 INPUT:
@ -368,31 +390,90 @@ GPG capable smart-cards SHOULD be loaded as follows: The encryption slot SHOULD
 However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves a dual purpose.
 ===DICE===
 Application number: 89101'
 The derivation path format is: <code>m/83696968'/89101'/{sides}'/{rolls}'/{index}'</code>
    2 <= sides <= 2^32 - 1
    1 <= rolls <= 2^32 - 1
 Use this application to generate PIN numbers, numeric secrets, and secrets over custom alphabets.
 For example, applications could generate alphanumeric passwords from a 62-sided die (26 + 26 + 10).
 Roll values are zero-indexed, such that an N-sided die produces values in the range
 <code>[0, N-1]</code>, inclusive. Applications should separate printed rolls by a comma or similar.
 Create a BIP85 DRNG whose seed is the derived entropy.
 Calculate the following integers:
    bits_per_roll = ceil(log_2(sides))
    bytes_per_roll = ceil(bits_per_roll / 8)
 Read <code>bytes_per_roll</code> bytes from the DRNG.
 Trim any bits in excess of <code>bits_per_roll</code> (retain the most
 significant bits). The resulting integer represents a single roll or trial.
 If the trial is greater than or equal to the number of sides, skip it and
 move on to the next one. Repeat as needed until all rolls are complete.
 INPUT:
 * MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
 * PATH: m/83696968'/89101'/6'/10'/0'
 OUTPUT
 * DERIVED ENTROPY=5e41f8f5d5d9ac09a20b8a5797a3172b28c806aead00d27e36609e2dd116a59176a738804236586f668da8a51b90c708a4226d7f92259c69f64c51124b6f6cd2
 * DERIVED ROLLS=1,0,0,2,0,1,5,5,2,4
 ==Backwards Compatibility==
 This specification is not backwards compatible with any other existing specification.
 This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics.
 ==Discussion==
 The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur.
 ==Acknowledgements==
 Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases.
 ==References==
 BIP32, BIP39
 ==Reference Implementations==
 * 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea]
 * 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85]
 * 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js]
 ==Changelog==
 ===1.3.0 (2024-10-22)===
 ====Added====
 * Dice application 89101'
 * Czech language code to application 39'
 * TPRV guidance for application 32'
 * Warning on application 32' key and chain code ordering
 ===1.2.0 (2022-12-04)===
 ====Added====
 * Base64 application 707764'
 * Base85 application 707785'
 ===1.1.0 (2020-11-19)===
 ====Added====
 * BIP85-DRNG-SHAKE256
 * RSA application 828365'
 ===1.0.0 (2020-06-11)===
 * Initial version
 ==Footnotes==
-[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users to iterate to the next index).
+<references />
-From BIP32:
+==Acknowledgements==
 In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.)
-==Copyright==
+Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases.
 This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
--- a/bip-0086.mediawiki
+++ b/bip-0086.mediawiki
@ -5,7 +5,7 @@
  Author: Ava Chow <me@achow101.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0086
-  Status: Draft
+  Status: Final
  Type: Standards Track
  Created: 2021-06-22
  License: BSD-2-Clause
--- a/bip-0087.mediawiki
+++ b/bip-0087.mediawiki
@ -48,7 +48,7 @@ The second multisignature "standard" in use is m/48', which specifies:
 m / purpose' / coin_type' / account' / script_type' / change / address_index
 </pre>
-Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script.  While it attempts to reduce maintainence work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, <code>script_type</code> list.
+Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script.  While it attempts to reduce maintenance work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, <code>script_type</code> list.
 The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type <ref>'''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only.</ref>.
@ -105,7 +105,7 @@ Hardened derivation is used at this level.
 It is crucial that this level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
 For example, before sending a new key record to a coordinator, the wallet must increment the <code>account'</code> level.
-This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types.
+This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and in between the same wallet types.
 ===Change===
--- a/bip-0088.mediawiki
+++ b/bip-0088.mediawiki
@ -27,7 +27,7 @@ This BIP is licensed under the 2-clause BSD license.
 BIP32 derivation path format is universal, and a number of schemes for derivation were proposed
 in BIP43 and other documents, such as BIPs 44,45,49,84. The flexibility of the format also allowed
-industry participants to implement custom derivation shemes that fit particular purposes,
+industry participants to implement custom derivation schemes that fit particular purposes,
 but not necessarily useful in general.
 Even when existing BIPs for derivation schemes are used, their usage is not uniform across
@ -41,18 +41,18 @@ addresses differently than the one they used before.
 The problem is common enough to warrant the creation of a dedicated website
 ([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets.
-At the time of writing, this website has used their own format to succintly describe multiple
+At the time of writing, this website has used their own format to succinctly describe multiple
-derivation paths. As far as author knows, it was the only publicitly used format to describe
+derivation paths. As far as author knows, it was the only publicly used format to describe
 path templates before introduction of this BIP. The format was not specified anywhere beside
 the main page of the website. It used <code>|</code> to denote alternative derivation indexes
 (example: <code>m/|44'|49'|84'/0'/0'</code>) or whole alternative paths (<code>m/44'/0'/0'|m/44'/1'/0'</code>).
 It was not declared as a template format to use for processing by software, and seems to be
 an ad-hoc format only intended for illustration. In contrast to this ad-hoc format, the format
-described in this BIP is intended for unambigouos parsing by software, and to be easily read by humans
+described in this BIP is intended for unambiguous parsing by software, and to be easily read by humans
 at the same time. Humans can visually detect the 'templated' parts of the path more easily than the use
 of <code>|</code> in the template could allow. Wider range of paths can be defined in a single template more
-succintly and unambiguously.
+succinctly and unambiguously.
 ===Intended use and advantages===
@ -71,7 +71,7 @@ into using well-known paths, or convince other vendors to support their custom p
 scales poorly.
 A flexible approach proposed in this document is to define a standard notation for "BIP32 path templates"
-that succintly describes the constraints to impose on the derivation path.
+that succinctly describes the constraints to impose on the derivation path.
 Wide support for these path templates will increase interoperability and flexibility of solutions,
 and will allow vendors and individual developers to easily define their own custom restrictions.
@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though.
 ==Specification==
-The format for the template was chosen to make it easy to read, convenient and visually unambigous. 
+The format for the template was chosen to make it easy to read, convenient and visually unambiguous.
 Template starts with optional prefix <code>m/</code>, and then one or more sections delimited by the slash character (<code>/</code>).
--- a/bip-0090.mediawiki
+++ b/bip-0090.mediawiki
@ -82,7 +82,7 @@ https://github.com/bitcoin/bitcoin/pull/8391.
 ==References==
-[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase] 
+[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase]
 [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 Strict DER signatures]
--- a/bip-0093.mediawiki
+++ b/bip-0093.mediawiki
@ -354,7 +354,7 @@ Instead every different language has it own word list (or word lists) and each c
 We would need to encode the choice of word list in our share's meta-data, which takes up even more room, and is difficult to specify due to the ever-evolving choice of word lists.
 Alternatively we could standardize on the choice of the English word list, something that is nearly a de facto standard, and simply be incompatible with BIP-0039 wallets of other languages.
-Such a choice also risks users of BIP-0039 recovering their entropy from their language, encoding it in in Codex32 and then failing to recover their wallet because the English word lists has replaced their language's word list.
+Such a choice also risks users of BIP-0039 recovering their entropy from their language, encoding it in Codex32 and then failing to recover their wallet because the English word lists has replaced their language's word list.
 The main advantage of this alternative approach would be that wallets could give users an option switch between backing up their entropy as a BIP-0039 mnemonic and in Codex32 format, but again, only if their language choice happens to be the English word list.
 In practice, we do not expect users in switch back and forth between backup formats, and instead just generate a fresh master seed using Codex32.
--- a/bip-0094.mediawiki
+++ b/bip-0094.mediawiki
@ -0,0 +1,120 @@
 <pre>
  BIP: 94
  Layer: Applications
  Title: Testnet 4
  Author: Fabian Jahr <fjahr@protonmail.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0094
  Status: Draft
  Type: Standards Track
  Created: 2024-05-27
  License: CC0-1.0
  Post-History: https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com/
                https://gnusha.org/pi/bitcoindev/a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg=@protonmail.com/
                https://github.com/bitcoin/bitcoin/pull/29775
 </pre>
 == Abstract ==
 A new test network with the goal to replace Testnet 3. This network comes with small but important improvements of the consensus rules, that should make it impractical to attack the network using only CPU mining.
 == Motivation ==
 Quoting the original mailing list post from Jameson Lopp<ref>https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com/</ref>:
 <blockquote><poem>
 Testnet3 has been running for 13 years. It's on block 2.5 million something and the block reward is down to ~0.014 TBTC, so mining is not doing a great job at distributing testnet coins anymore.
 The reason the block height is insanely high is due to a rather amusing edge case bug that causes the difficulty to regularly get reset to 1, which causes a bit of havoc. If you want a deep dive into the quirk: https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
 Testnet3 is being actively used for scammy airdrops; those of us who tend to be generous with our testnet coins are getting hounded by non-developers chasing cheap gains.
 As a result, TBTC is being actively bought and sold; one could argue that the fundamental principle of testnet coins having no value has been broken.
 </poem></blockquote>
 Since then the issue with block storms has been further demonstrated on Testnet 3 when three years' worth of blocks were mined in a few weeks while rendering the network practically unusable at the same time.
 == Specification ==
 Consensus of Testnet 4 follows the same rules as mainnet with the exception of the three rules detailed below. Additionally all soft forks that are active on mainnet as of May 2024 are enforced from genesis.
 === 20-minute Exception ===
 This rule was already previously implemented and active in Testnet 3<ref>https://github.com/bitcoin/bitcoin/pull/686</ref>.
 A block with a timestamp that is more than 20 minutes past the timestamp of the previous block must have a minimum difficulty of 1 (the network's minimum difficulty) instead of whatever the actual difficulty level currently is. This applies to all blocks in a difficulty period except for the first block. This means the blocks must change their <code>nBits</code> field from the actual difficulty level to the minimum difficulty value <code>0x1d00ffff</code>.
 This rule also led to the block storms<ref>https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/</ref> which the following rule seeks to fix.
 === Block Storm Fix ===
 The work required for a new difficulty period is calculated as multiplication factor to the difficulty of the previous period (but no less than 1/4th and no more than 4x), depending on the duration of the previous difficulty period. On Mainnet and Testnet 3, this factor is applied to the difficulty value of the last block.
 Block storms happen organically whenever the 20-minute exception is applied to a difficulty period’s last block, causing the block to be mined at a difficulty of 1. The difficulty adjustment rules then limit the subsequent period’s difficulty to a value between 1 (the minimum) and 4. Blocks will be generated rapidly in the subsequent low-difficulty periods while the difficulty climbs back to an adequate range. An arbitrarily large number of blocks can be generated quickly by repeatedly using the 20-minute exception on every last block of difficulty periods. The block storm is then bounded only by miner hash rate, the need for last blocks to have a timestamp 20 minutes after the second to last block, the Median-Time-Past nTime rule, and the requirement that blocks can't be more than 2 hours in the future. Overall a sustained attack would eventually be limited to a maximum cadence of six blocks per second.
 A block storm does not require a time warp attack, but one can be used to amplify<ref>A perpetual block storm attack with entire difficulty periods being authored in less than 3.5 days that resets the difficulty to the minimum in the last block of every difficulty period would adjust to a new actual difficulty of 4 every period. An attacker that additionally leverages a time warp attack would start their attack by holding back timestamps until the latest block’s timestamp is at least two weeks in the past, and then limiting their block rate to six blocks per second, incrementing the timestamp on every sixth block. Only on the last block they would use the current time, which both resets the difficulty to one per the 20-minute exception and would result in a difficulty adjustment keeping the difficulty at the minimum due to the elapsed time exceeding the target. This would allow lower the difficulty for all blocks to difficulty 1 instead of difficulty 4</ref> it.
 The mitigation consists of no longer applying the adjustment factor to the last block of the previous difficulty period. Instead, the first block of the difficulty period is used as the base.
 The first block must contain the actual difficulty of the network and can therefore be used as the base for the calculation of the new difficulty level. Note that the first block in new difficulty period does not allow usage of the 20-minute exception (this is prior behavior). This means that in each difficulty period the first block should always have the actual difficulty even if all other blocks were mined with the 20-minute exception.
 === Time Warp Fix ===
 In addition to a time warp attack potentially exacerbating the perpetual block storm attack, a time warp attack provides an alternative way to increase the block production rate even if the unintended reset of the actual difficulty due to the 20-minute exception was mitigated.
 To protect against the time warp attack, the following rule proposed as part of The Great Consensus Cleanup<ref>https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki</ref> is enforced: "The nTime field of each block whose height, mod 2016, is 0 must be greater than or equal to the nTime field of the immediately prior block minus 600. For the avoidance of doubt, such blocks must still comply with existing Median-Time-Past nTime restrictions."
 == Rationale ==
 The applied changes were the result of discussions on the mailing list and the PR. The selected changes try to strike a balance between minimal changes to the network (keeping it as close to mainnet as possible) while making it more robust against attackers that try to disrupt the network. Several alternative designs were considered:
 * For the block storm fix an alternative fix could have been to prevent the last block in a difficulty period from applying the existing difficulty exception. Both solutions were deemed acceptable and there was no clear preference among reviewers.
 * Removal of the 20-minute exception was discussed but dismissed since several reviewers insisted that it was a useful feature allowing non-standard transactions to be mined with just a CPU. The 20-minute exception also allows CPU users to move the chain forward (except on the first block that needs to be mined at actual difficulty) in case a large amount of hash power suddenly leaves the network. This would allow the chain to recover to a normal difficulty level faster if left stranded at high difficulty.
 * Increase of minimum difficulty was discussed but dismissed as it would categorically prevent participation in the network using a CPU miner (utilizing the 20-minute exception).
 * Increase of the delay in the 20-minute exception was suggested but did not receive significant support.
 * Re-enabling <code>acceptnonstdtxn</code> in bitcoin core by default was dismissed as it had led to confusion among layer-2s that had used testnet for transaction propagation tests and expected it to behave similar to mainnet.
 * Motivating miners to re-org min difficulty blocks was suggested, but was considered out of scope for this BIP, since adoption of such a mining policy remains available after Testnet 4 is deployed. As 20-minute exception blocks only contribute work corresponding to difficulty one to the chaintip, and actual difficulty blocks should have a difficulty magnitudes higher, a block mined at actual difficulty could easily replace even multiple 20-minute exception blocks.
 * Persisting the real difficulty in the version field was suggested to robustly prevent exploits of the 20-minute exception while allowing it to be used on any block, but did not receive a sufficient level of support to justify the more invasive change.
 One known downside of the chosen approach is that if the difficulty is gradually raised by a miner with significant hash rate, and this miner disappears, then each difficulty adjustment period requires one block at the actual difficulty.
 This would cause the network to stall once per difficulty adjustment period until the real difficulty is adjusted downwards enough for the remaining hash rate to find this block in reasonable time.
 == Network Parameters ==
 === Consensus Rules ===
 All consensus rules active on mainnet at the time of this proposal are enforced from block 1, the newest of these rules being the Taproot softfork.
 === Genesis Block ===
 * Message: <code>03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e</code>
 * Pubkey: <code>000000000000000000000000000000000000000000000000000000000000000000</code>
 * Time stamp: 1714777860
 * Nonce: 393743547
 * Difficulty: <code>0x1d00ffff</code>
 * Version: 1
 The resulting genesis block hash is <code>00000000da84f2bafbbc53dee25a72ae507ff4914b867c565be350b0da8bf043</code>, and the block hex is <code>0100000000000000000000000000000000000000000000000000000000000000000000004e7b2b9128fe0291db0693af2ae418b767e657cd407e80cb1434221eaea7a07a046f3566ffff001dbb0c78170101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5504ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065ffffffff0100f2052a010000002321000000000000000000000000000000000000000000000000000000000000000000ac00000000</code>.
 === Message Start ===
 The message start is defined as <code>0x1c163f28</code>. These four bytes were randomly generated and have no special meaning.
 == Backwards Compatibility ==
 The rules used by Testnet 4 are backwards compatible to the rules of Testnet 3. Existing software that implements support for Testnet 3 would only require addition of the network parameters  (magic number, genesis block, etc.) to be able to follow Testnet 4. 
 However, implementations that only implement Testnet 3’s rules would accept a chain that violates Testnet 4’s rules and are therefore susceptible to being forked off. It is recommended that any implementations check blocks in regard to all the new rules of Testnet 4 and reject blocks that fail to comply.
 == Reference implementation ==
 Pull request at https://github.com/bitcoin/bitcoin/pull/29775
 == References ==
 <references/>
 == Copyright ==
 This document is licensed under the  Creative Commons CC0 1.0 Universal license.
--- a/bip-0098.mediawiki
+++ b/bip-0098.mediawiki
@ -63,7 +63,7 @@ Nodes with single children are not allowed.
 The ''double-SHA256'' cryptographic hash function takes an arbitrary-length data as input and produces a 32-byte hash by running the data through the SHA-256 hash function as specified in FIPS 180-4[3], and then running the same hash function again on the 32-byte result, as a protection against length-extension attacks.
-The ''fast-SHA256'' cryptographic hash function takes two 32-byte hash values, concatenates these to produce a 64-byte buffer, and applies a single run of the SHA-256 hash function with a custom 'initialization vector' (IV) and without message paddding.
+The ''fast-SHA256'' cryptographic hash function takes two 32-byte hash values, concatenates these to produce a 64-byte buffer, and applies a single run of the SHA-256 hash function with a custom 'initialization vector' (IV) and without message padding.
 The result is a 32-byte 'midstate' which is the combined hash value and the label of the inner node.
 The changed IV protects against path-length extension attacks (grinding to interpret a hash as both an inner node and a leaf).
 fast-SHA256 is only defined for two 32-byte inputs.
@ -241,16 +241,16 @@ Disallowing a node with two SKIP branches eliminates what would otherwise be a s
 The number of hashing operations required to verify a proof is one less than the number of hashes (SKIP and VERIFY combined),
 and is exactly equal to the number of inner nodes serialized as the beginning of the proof as N.
-The variable-length integer encoding has the property that serialized integers, sorted lexigraphically, will also be sorted numerically.
+The variable-length integer encoding has the property that serialized integers, sorted lexicographically, will also be sorted numerically.
-Since the first serialized item is the number of inner nodes, sorting proofs lexigraphically has the effect of sorting the proofs by the amount of work required to verify.
+Since the first serialized item is the number of inner nodes, sorting proofs lexicographically has the effect of sorting the proofs by the amount of work required to verify.
 The number of hashes required as input for verification of a proof is N+1 minus the number of SKIP hashes,
 and can be quickly calculated without parsing the tree structure.
-The coding and packing rules for the serialized tree structure were also chosen to make lexigraphical comparison useful (or at least not meaningless).
+The coding and packing rules for the serialized tree structure were also chosen to make lexicographical comparison useful (or at least not meaningless).
 If we consider a fully-expanded tree (no SKIP hashes, all VERIFY) to be encoding a list of elements in the order traversed depth-first from left-to-right,
 then we can extract proofs for subsets of the list by SKIP'ing the hashes of missing values and recursively pruning any resulting SKIP,SKIP nodes.
-Lexigraphically comparing the resulting serialized tree structures is the same as lexigraphically comparing lists of indices from the original list verified by the derived proof.
+Lexicographically comparing the resulting serialized tree structures is the same as lexicographically comparing lists of indices from the original list verified by the derived proof.
 Because the number of inner nodes and the number of SKIP hashes is extractible from the tree structure,
 both variable-length integers in the proof are redundant and could have been omitted.
--- a/bip-0099.mediawiki
+++ b/bip-0099.mediawiki
@ -23,7 +23,7 @@ not always well-understood, and the best upgrade mechanisms to the
 consensus validation rules may vary depending on the type of change being deployed.
 Discussing such changes without a uniform view on the deployment
 paths often leads to misunderstandings and unnecessarily delays the
-deployment of changes. 
+deployment of changes.
 ==Definitions==
@ -43,7 +43,7 @@ deployment of changes.
 : a theoretical piece of software that contains the specifications that define the validity of a block for a given state and chain parameters (ie it may act differently on, for example, regtest).
 ;Libbitcoinconsensus
-: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line 
+: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line
 ==Taxonomy of consensus forks==
@ -76,14 +76,14 @@ without burdening them with specific design choices made by Bitcoin
 Core. It is to be noted that sharing the same code for consensus
 validation doesn't prevent alternative implementations from
 independently changing their consensus rules: they can always fork
-the libbitcoinconsensus project (once it is in a separate repository). 
+the libbitcoinconsensus project (once it is in a separate repository).
 Hopefully libbitcoinconsensus will remove this type of consensus fork
 which - being accidental - obviously doesn't need a deployment plan.
 ====11/12 March 2013 Chain Fork====
-There is a precedent of an accidental consensus fork at height 225430. 
+There is a precedent of an accidental consensus fork at height 225430.
 Without entering into much detail (see [2]), the situation was different from
 what's being described from the alternative implementation risks (today alternative implementation
 still usually rely in different degrees on Bitcoin Core trusted proxies, which
@ -104,7 +104,7 @@ rapidly by the whole worldwide community and nobody is unhappy about
 the solution.
 But there's some philosophical disagreements on the terms of what the
-solution was: we can add a pedantic note on that.   
+solution was: we can add a pedantic note on that.
 If "the implementation is the specification", then those
 levelDB-specific limitations were part of the consensus rules.
 Then additional rules were necessary and any alternative
@ -113,7 +113,7 @@ planned consensus fork to migrate all Bitcoin-qt 0.7- users could
 remove those additional consensus restrictions.
 Had libconsensus being implemented without depending on levelDB,
 those additional restrictions wouldn't have been part of "the specification"
- and this would just have been a bug in the
+and this would just have been a bug in the
 consensus rules, just a consensus-critical bug in a set of
 implementations, concretely all satoshi-bitcoin-0.7-or-less (which
 happened to be a huge super majority of the users), but other
@ -126,7 +126,7 @@ another consensus fork to remove them. Two theoretical consensus forks
 instead of one but the first one deployed practically for free. The
 practical result would have been identical and only the definitions
 change. This means discussing something that went uncontroversially
-well further is "philosophical bike-shed" (TM).  
+well further is "philosophical bike-shed" (TM).
 ===Unilateral softforks===
@ -157,17 +157,17 @@ that this must always be the case.
 While 2 chains cohexist, they can be considered two different
 currencies.
 We could say that bitcoin becomes bitcoinA and bitcoinB. The implications for market
-capitalization are completely unpredictable, 
+capitalization are completely unpredictable,
-maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin), 
+maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin),
-maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin), 
+maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin),
 maybe mc(bitcoinA) + mc(bitcoinB) = 1000 * mc(old_bitcoin),
 maybe mc(bitcoinA) + mc(bitcoinB) = 0,
-... 
+...
 Schism hardforks have been compared to one type of altcoins called
 "spinoffs"[spinoffs] that distribute all or part of its initial seigniorage to
@ -224,7 +224,7 @@ Let's imagine BIP66 had a crypto backdoor
 that nobody noticed and allows an evil developer cabal to steal
 everyone's coins. The users and non-evil developers could join, fork
 libconsensus and use the forked version in their respective bitcoin
-implementations. 
+implementations.
 Should miner's "vote" be required to express their consent? What if some miners
 are part of the cabal? In the unlikely event that most miners are
 part of such an evil cabal, changing the pow function may be
@ -268,7 +268,7 @@ that's why the voting mechanism and first used for BIP30 and BIP66.
 The current voting threshold for softfork enforcement is 95%. There's
 also a 75% threshold for miners to activate it as a policy rule, but
 it should be safe for miners to activate such a policy from the start
-or later than 75%, as long as they enforce it as consensus rule after 95%. 
+or later than 75%, as long as they enforce it as consensus rule after 95%.
 The current miners' voting mechanism can be modified to allow for
 changes to be deployed in parallel, the rejection of a concrete
@ -355,12 +355,12 @@ worth of blocks).
 [5] Original references:
 https://bitcointalk.org/index.php?topic=114751.0
 https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
-Rebased patch: 
+Rebased patch:
 https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14
 ==Attribution==
-Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, 
+Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop,
 Btcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke.
 ==Copyright==
--- a/bip-0104.mediawiki
+++ b/bip-0104.mediawiki
@ -65,7 +65,7 @@ A hardcoded increase to max block size (2MB, 8MB, etc.), rejected because:
 Allow miners to vote for max block size, rejected because:
 * overly complex and political
 * human involvement makes this slow to respond to changing transaction volumes
-* focuses power over max block size to a relatively small group of people 
+* focuses power over max block size to a relatively small group of people
 * unpredictable transaction fees caused by this would create uncertainty in the ecosystem
 ==Backward Compatibility==
--- a/bip-0105.mediawiki
+++ b/bip-0105.mediawiki
@ -13,21 +13,21 @@
 ==Abstract==
-A method of altering the maximum allowed block size of the Bitcoin protocol 
+A method of altering the maximum allowed block size of the Bitcoin protocol
 using a consensus based approach.
 ==Motivation==
-There is a belief that Bitcoin cannot easily respond to raising the 
+There is a belief that Bitcoin cannot easily respond to raising the
-blocksize limit if popularity was to suddenly increase due to a mass adoption 
+blocksize limit if popularity was to suddenly increase due to a mass adoption
-curve, because co-ordinating a hard fork takes considerable time, and being 
+curve, because co-ordinating a hard fork takes considerable time, and being
-unable to respond in a timely manner would irreparably harm the credibility of 
+unable to respond in a timely manner would irreparably harm the credibility of
 bitcoin.
 Additionally, predetermined block size increases are problematic because they
-attempt to predict the future, and if too large could have unintended 
+attempt to predict the future, and if too large could have unintended
-consequences like damaging the possibility for a fee market to develop 
+consequences like damaging the possibility for a fee market to develop
-as block subsidy decreases substantially over the next 9 years; introducing 
+as block subsidy decreases substantially over the next 9 years; introducing
 or exacerbating mining attack vectors; or somehow affect the network in unknown
 or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
 extensive.
@ -36,14 +36,14 @@ Dynamic block size adjustments also suffer from the potential to be gamed by the
 larger hash power.
 Free voting as suggested by BIP100 allows miners to sell their votes out of band
-at no risk, and enable the sponsor the ability to manipulate the blocksize. 
+at no risk, and enable the sponsor the ability to manipulate the blocksize.
 It also provides a cost free method or the larger pools to vote in ways to
 manipulate the blocksize such to disadvantage or attack smaller pools.
 ==Rationale==
-By introducing a cost to increase the block size ensures the mining community 
+By introducing a cost to increase the block size ensures the mining community
 will collude to increase it only when there is a clear necessity, and reduce it
 when it is unnecessary. Larger miners cannot force their wishes so easily
 because not only will they have to pay extra a difficulty target, then can be
@ -63,7 +63,7 @@ honest.
 The initial block size limit shall be 1MB.
 Each time a miner creates a block, they may vote to increase or decrease the
-blocksize by a maximum of 10% of the current block size limit. These votes will 
+blocksize by a maximum of 10% of the current block size limit. These votes will
 be used to recalculate the new block size limit every 2016 blocks.
 Votes are cast using the block's coinbase transaction scriptSig.
@ -77,7 +77,7 @@ If a miner votes for an increase, the block hash must meet a difficulty target
 which is proportionally larger than the standard difficulty target based on the
 percentage increase they voted for.
-Votes proposing decreasing the block size limit do not need to meet a higher 
+Votes proposing decreasing the block size limit do not need to meet a higher
 difficulty target.
 Miners can vote for no change by voting for the current block size.
--- a/bip-0106.mediawiki
+++ b/bip-0106.mediawiki
@ -36,13 +36,13 @@ https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&
      Keep the same MaxBlockSize
 ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners===
-  
+
  TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period
  TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
-  
+
  TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period
  TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
-  
+
  If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) )
      MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty
  Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) )
--- a/bip-0107.mediawiki
+++ b/bip-0107.mediawiki
@ -24,7 +24,7 @@ Over the next few years, large infrastructure investments will be made into:
 # Layer 2 services and networks for off-chain transactions
 # General efficiency improvements to transactions and the blockchain
-* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. 
+* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network.
 * In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'.
 * These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network.
@ -40,7 +40,7 @@ Over the next few years, large infrastructure investments will be made into:
 * '''Phase 2'''
 ** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume
 ** Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur
-*** This calculates to a theoretical maximum of 13 increases per year 
+*** This calculates to a theoretical maximum of 13 increases per year
 ** IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10%
 ** The maximum block size can only ever be increased, not decreased
 * The default <code>limitfreerelay</code> will also be raised in proportion to maximum block size increases
@ -49,8 +49,8 @@ Over the next few years, large infrastructure investments will be made into:
 For example:
 * When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size will be 6 MB
-* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. 
+* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB.
-* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. 
+* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year.
 ==Rationale==
@ -63,19 +63,19 @@ For example:
 *** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place
 *** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size
 **** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered
-*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. 
+*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit.
 ** Why 3025 blocks?
 *** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1
 *** Increases in the maximum block size should only occur after a sustained trend can be observed in order to:
 ***# Demonstrate a market-driven secular elevation in the transaction volume
-***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions   
+***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions
 *** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand
 ** Why 10% increase in the block size?
 *** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunities  to increase the block size per year
-*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community 
+*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community
 ==Deployment==
-Similar deployment model to BIP101:  
+Similar deployment model to BIP101:
 <blockquote>Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks.</blockquote>
 ==Acknowledgements==
--- a/bip-0109.mediawiki
+++ b/bip-0109.mediawiki
@ -65,7 +65,7 @@ SPV (simple payment validation) wallets are compatible with this change.
 ==Rationale==
-In the short term, an increase is needed to handle increasing transaction volume. 
+In the short term, an increase is needed to handle increasing transaction volume.
 The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software.
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@ -69,13 +69,13 @@ address with the following redeemscript.
        <Alice's pubkey> CHECKSIG
    ENDIF
-At any time funds can be spent using signatures from any two of Alice, 
+At any time funds can be spent using signatures from any two of Alice,
 Bob or the Escrow.
 After 30 days Alice can sign alone.
 The clock does not start ticking until the payment to the escrow address
-confirms. 
+confirms.
 ===Retroactive Invalidation===
@ -230,7 +230,7 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics
 ==Specification==
-Refer to the reference implementation, reproduced below, for the precise 
+Refer to the reference implementation, reproduced below, for the precise
 semantics and detailed rationale for those semantics.
 <pre>
@ -247,7 +247,7 @@ static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
 /* If CTxIn::nSequence encodes a relative lock-time, this mask is
 * applied to extract that lock-time from the sequence field. */
 static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
-   
+
 case OP_NOP3:
 {
    if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
@ -290,7 +290,7 @@ case OP_NOP3:
    break;
 }
-    
+
 bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
 {
    // Relative lock times are supported by comparing the passed
--- a/bip-0113.mediawiki
+++ b/bip-0113.mediawiki
@ -45,13 +45,13 @@ BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY).
 ==Specification==
-The values for transaction locktime remain unchanged. The difference is only in 
+The values for transaction locktime remain unchanged. The difference is only in
-the calculation determining whether a transaction can be included. Instead of 
+the calculation determining whether a transaction can be included. Instead of
-an unreliable timestamp, the following function is used to determine the current 
+an unreliable timestamp, the following function is used to determine the current
 block time for the purpose of checking lock-time constraints:
    enum { nMedianTimeSpan=11 };
-    
+
    int64_t GetMedianTimePast(const CBlockIndex* pindex)
    {
        int64_t pmedian[nMedianTimeSpan];
--- a/bip-0114.mediawiki
+++ b/bip-0114.mediawiki
@ -111,7 +111,7 @@ The advantages of the current proposal are:
 * If different parties in a contract do not want to expose their scripts to each other, they may provide only <code>H(Subscript)</code> and keep the <code>Subscript</code> private until redemption.
 * If they are willing to share the actual scripts, they may combine them into one <code>Subscript</code> for each branch, saving some <code>nOpCount</code> and a few bytes of witness space.
-The are some disadvantages, but only when the redemption condition is very complicated:
+There are some disadvantages, but only when the redemption condition is very complicated:
 * It may require more branches than a general MAST design (as shown in the previous example) and take more witness space in redemption
 * Creation and storage of the MAST structure may take more time and space. However, such additional costs affect only the related parties in the contract but not any other Bitcoin users.
--- a/bip-0115.mediawiki
+++ b/bip-0115.mediawiki
@ -98,7 +98,7 @@ What if ParamBlockHash has leading zeros? Should this be prevented?
 * If leading zeros are included, they should be compared to the actual block hash. (If they were truncated, fewer bytes would be compared.)
 * It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern.
-* Since all block hashes are in principle shorter than than 29 bytes, ParamBlockHash may not be larger than 28 bytes.
+* Since all block hashes are in principle shorter than 29 bytes, ParamBlockHash may not be larger than 28 bytes.
 Why is it safe to allow checking blocks as recently as the immediate previous block?
--- a/bip-0116.mediawiki
+++ b/bip-0116.mediawiki
@ -59,7 +59,7 @@ This includes execution pathways or policy conditions which end up not being nee
 Not only is it inefficient to require this unnecessary information to be present on the blockchain, albeit in the witness, it also impacts privacy and fungibility as some unused script policies may be identifying.
 Using a Merkle hash tree to commit to the policy options, and then only forcing revelation of the policy used at redemption minimizes this information leakage.
-Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would would otherwise be possible, due to various built-in script size and runtime limitations.
+Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would otherwise be possible, due to various built-in script size and runtime limitations.
 With Merkle commitments to policy these size and runtime limitations constrain the complexity of any one policy that can be used rather than the sum of all possible policies.
 ==Rationale==
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@ -3,7 +3,6 @@
  Layer: Consensus (soft fork)
  Title: CHECKTEMPLATEVERIFY
  Author: Jeremy Rubin <j@rubin.io>
          James O'Beirne <vaults@au92.org>
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119
  Status: Draft
  Type: Standards Track
@ -193,7 +192,7 @@ Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.
 The Bitcoin Core reference implementation includes the below parameters,
 configured to match Speedy Trial, as that is the current activation mechanism
 implemented in Bitcoin Core. Should another method become favored by the wider
-Bitcoin comminity, that might be used instead.
+Bitcoin community, that might be used instead.
 The start time and bit in the implementation are currently set to bit 5 and
 NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft.
@ -314,7 +313,7 @@ We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decodi
 to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also
 friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that
 the max inputs in a block is further restricted by the block size to around 25,000, which would fit
-into a `uint16_t`, but that is an uneccessary abstraction leak.
+into a `uint16_t`, but that is an unnecessary abstraction leak.
 =====Committing to the Sequences Hash=====
@ -362,7 +361,7 @@ scripts cannot be spent at the same index, which implies that they cannot be spe
 This makes it safer to design wallet vault contracts without half-spend vulnerabilities.
 Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can
-be spent at multiple indicies. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped
+be spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped
 in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are
 added to Bitcoin, the index may simply be passed in by the witness before hashing.
@ -392,7 +391,7 @@ transaction preimages.
 =====Using Non-Tagged Hashes=====
 The Taproot/Schnorr BIPs use Tagged Hashes
-(`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leafs, branches,
+(`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leaves, branches,
 tweaks, and signatures from overlapping in a way that might introduce a security
 [vulnerability https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html].
@ -476,7 +475,7 @@ An example of a script that could experience an DoS issue without caching is:
    <H> CTV CTV CTV... CTV
-Such a script would cause the intepreter to compute hashes (supposing N CTV's) over O(N*T) data.
+Such a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data.
 If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N)
 times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations
 over all variable length fields in a transaction.
@ -494,7 +493,7 @@ The preimage argument passed to CHECKTEMPLATEVERIFY may be unknown or otherwise
 However, requiring knowledge that an address is spendable from is incompatible with sender's ability
 to spend to any address (especially, OP_RETURN). If a sender needs to know the template can be spent
 from before sending, they may request a signature of an provably non-transaction challenge string
-from the leafs of the CHECKTEMPLATEVERIFY tree.
+from the leaves of the CHECKTEMPLATEVERIFY tree.
 ====Forwarding Addresses====
@ -504,7 +503,7 @@ For example, a exchange's hot wallet might use an address which can automaticall
 storage address after a relative timeout.
 The issue is that reusing addresses in this way can lead to loss of funds.
-Suppose one creates an template address which forwards 1 BTC to cold storage.
+Suppose one creates a template address which forwards 1 BTC to cold storage.
 Creating an output to this address with less than 1 BTC will be frozen permanently.
 Paying more than 1 BTC will lead to the funds in excess of 1BTC to be paid as a large miner fee.
 CHECKTEMPLATEVERIFY could commit to the exact amount of bitcoin provided by the inputs/amount of fee
@ -616,7 +615,7 @@ sponsors might be considered.
 An opcode which verifies the exact amount that is being spent in the
 transaction, the amount paid as fees, or made available in a given output could
-be used to make safer OP_CHECKTEMPLATEVERIFY addressses. For instance, if the
+be used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the
 OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1
 satoshis would result in a frozen UTXO and sending S+n satoshis would result in
 n satoshis being paid to fee. A range check could restrict the program to only
--- a/bip-0120.mediawiki
+++ b/bip-0120.mediawiki
@ -52,7 +52,7 @@ A proof of payment for a transaction T, here called PoP(T), is used to prove tha
 OP_RETURN <version> <txid> <nonce>
-{|        
+{|
 ! Field        !! Size [B] !! Description
 |-
 | &lt;version> || 2        || Version, little endian, currently 0x01 0x00
@ -77,7 +77,7 @@ An illustration of the PoP data structure and its original payment is shown belo
 |input2 4,ffffffff     | 1,pay to B              |
 |                      | 4,pay to C              |
 +------------------------------------------------+
- 
+
  PoP(T)
 +-------------------------------------------------------------+
 | inputs               | outputs                              |
--- a/bip-0122.mediawiki
+++ b/bip-0122.mediawiki
@ -43,7 +43,7 @@ Where:
 | rowspan="3" | type
 | tx
 | for transactions.
-| rowspan="3" | required 
+| rowspan="3" | required
 |-
 | block
 | for blocks (supports both hash or height).
@ -75,9 +75,9 @@ The '''chain ID''' of a chain is the block hash of the corresponding genesis blo
 So, for example:
 <pre>
-Bitcoin main   : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 
+Bitcoin main   : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
 Bitcoin test   : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
-Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 
+Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206
 </pre>
 An example of forked chain (Feathercoin, that forked Litecoin):
@ -87,7 +87,7 @@ An example of forked chain (Feathercoin, that forked Litecoin):
 <pre>
 Litecoin   : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2
 Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb
-</pre>  
+</pre>
 ==Examples==
--- a/bip-0123.mediawiki
+++ b/bip-0123.mediawiki
@ -72,7 +72,7 @@ There's room at this layer to allow for competing standards without breaking bas
 ===4. Applications Layer===
-The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data. 
+The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.
 ==Classification of existing BIPs==
--- a/bip-0125.mediawiki
+++ b/bip-0125.mediawiki
@ -6,7 +6,7 @@
          Peter Todd <pete@petertodd.org>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0125
-  Status: Proposed
+  Status: Final
  Type: Standards Track
  Created: 2015-12-04
  License: PD
@ -151,8 +151,8 @@ of full-RBF.
 There are no known problematic interactions between opt-in full-RBF and
 other uses of nSequence. Specifically, opt-in full-RBF is compatible
 with consensus-enforced locktime as provided in the Bitcoin 0.1
-implementation, draft BIP68 (Relative lock-time using consensus-enforced
+implementation, BIP68 (Relative lock-time using consensus-enforced
-sequence numbers), and draft BIP112 (CHECKSEQUENCEVERIFY).
+sequence numbers), and BIP112 (CHECKSEQUENCEVERIFY).
 ==Deployment==
--- a/bip-0129.mediawiki
+++ b/bip-0129.mediawiki
@ -95,7 +95,7 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
 * If all key records look good, the Coordinator fills in all necessary information to generate a descriptor record.
 * The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be a descriptor or a descriptor template. The third line must be a comma-separated list of derivation path restrictions. The paths must start with <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. The fourth line must be the wallet's first address. If there are path restrictions, use the first address from the first path restriction.
-* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
+* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption..
 * The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
 * The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
 * The Coordinator sends the encrypted descriptor record to all participating Signers.
@ -110,7 +110,7 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Signer checks that its <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof.
 * The Signer verifies that it is compatible with the derivation path restrictions.
 * The Signer verifies that the wallet's first address is valid.
-* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template must also be available for review upon user request. 
+* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template must also be available for review upon user request.
 * Parties must check with each other that all Signers have the same confirmation (except for the <tt>KEY</tt> positions).
 * If all checks pass, the Signer must persist the descriptor record in its storage.
@ -126,8 +126,8 @@ We define three modes of encryption.
 # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
 The <tt>TOKEN</tt> can be converted to one of these formats:
-* A decimal number (recommended). The number must not exceed the maximum value of the nonce. 
+* A decimal number (recommended). The number must not exceed the maximum value of the nonce.
-* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics. 
+* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics.
 * A QR code.
 * Other formats.
--- a/bip-0130.mediawiki
+++ b/bip-0130.mediawiki
@ -5,7 +5,7 @@
  Author: Suhas Daftuar <sdaftuar@chaincode.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130
-  Status: Proposed
+  Status: Final
  Type: Standards Track
  Created: 2015-05-08
  License: PD
--- a/bip-0132.mediawiki
+++ b/bip-0132.mediawiki
@ -83,7 +83,7 @@ The author doesn't believe this is a problem because a BIP cannot be forced on c
 ** User communities
 * A person may be represented by any number of segments, but a committee cannot re-use the same resource as another committee in the same segment.
-'''Committee Declarations.''' 
+'''Committee Declarations.'''
 * At any point, a Committee Declaration can be posted.
 * This Declaration must contain details about:
 ** The segment the Committee is representing
--- a/bip-0134.mediawiki
+++ b/bip-0134.mediawiki
@ -58,7 +58,7 @@ various decades ago with the XML format. The idea is that we give each
 field a name and this means that new fields can be added or optional fields
 can be omitted from individual transactions. Some other ideas are the
 standardization of data-formats (like integer and string encoding) so
-we create a more consistent system.  
+we create a more consistent system.
 One thing we shall not inherit from XML is its text-based format. Instead
 we use the [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Compact Message Format]
 (CMF) which is optimized to keep the size small and fast to parse.
--- a/bip-0135.mediawiki
+++ b/bip-0135.mediawiki
@ -170,7 +170,7 @@ A given deployment SHALL remain in the DEFINED state until it either passes the
 starttime (and becomes STARTED) or the timeout time (and becomes FAILED).
 Once a deployment has STARTED, the signal for that deployment SHALL be tallied
-over the the past windowsize blocks whenever a new block is received on that
+over the past windowsize blocks whenever a new block is received on that
 chain.
 A transition from the STARTED state to the LOCKED_IN state SHALL only occur
@ -183,7 +183,7 @@ when all of these are true:
 A similar height synchronization precondition SHALL exist for the transition from
 LOCKED_IN to ACTIVE.
 These synchronization conditions are expressed by the "mod(height, windowsize) = 0"
-clauses in the diagram, and have been been added so that backward compatibility
+clauses in the diagram, and have been added so that backward compatibility
 with BIP9's use of the 2016-block re-targeting periods can be configured for
 existing deployments (see above 'Optional full backward compatibility' section).
@ -261,7 +261,7 @@ proposal, although a conventional fallow period of 3 months is RECOMMENDED.
 Due to the constraints set by BIP 34, BIP 66 and BIP 65, there are only
 0x7FFFFFFB possible nVersion values available. This limits to at most 30
 independent deployments.
-By restricting the top 3 bits to 001 we we are left with 29 out of those for
+By restricting the top 3 bits to 001 we are left with 29 out of those for
 the purposes of this proposal, and support two future upgrades for different
 mechanisms (top bits 010 and 011).
--- a/bip-0137.mediawiki
+++ b/bip-0137.mediawiki
@ -15,7 +15,7 @@
 This document describes a signature format for signing messages with Bitcoin private keys.
-The specification is intended to describe the standard for signatures of messages that can be signed and verfied between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme.
+The specification is intended to describe the standard for signatures of messages that can be signed and verified between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme.
 One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures.
--- a/bip-0140.mediawiki
+++ b/bip-0140.mediawiki
@ -62,7 +62,7 @@ This is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bi
 The existing <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code> have a bug<ref>[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]]</ref> that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary.
 The normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed.
-The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures.
+The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transaction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures.
 === Tracking Normalized Transaction IDs ===
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@ -43,13 +43,13 @@ By removing this data from the transaction structure committed to the transactio
 A new data structure, <code>witness</code>, is defined. Each transaction will have 2 IDs.
 Definition of <code>txid</code> remains unchanged: the double SHA256 of the traditional serialization format:
-  
+
  [nVersion][txins][txouts][nLockTime]
-  
+
 A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data:
-  
+
  [nVersion][marker][flag][txins][txouts][witness][nLockTime]
-  
+
 Format of <code>nVersion</code>, <code>txins</code>, <code>txouts</code>, and <code>nLockTime</code> are same as traditional serialization.
 The <code>marker</code> MUST be a 1-byte zero value: <code>0x00</code>.
@ -67,14 +67,14 @@ A new block rule is added which requires a commitment to the <code>wtxid</code>.
 A <code>witness root hash</code> is calculated with all those <code>wtxid</code> as leaves, in a way similar to the <code>hashMerkleRoot</code> in the block header.
 The commitment is recorded in a <code>scriptPubKey</code> of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is:
-  
+
   1-byte - OP_RETURN (0x6a)
   1-byte - Push the following 36 bytes (0x24)
   4-byte - Commitment header (0xaa21a9ed)
  32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value)
-  
+
  39th byte onwards: Optional data with no consensus meaning
-  
+
 and the coinbase's input's witness must consist of a single 32-byte array for the <code>witness reserved value</code>.
 If there are more than one <code>scriptPubKey</code> matching the pattern, the one with highest output index is assumed to be the commitment.
--- a/bip-0142.mediawiki
+++ b/bip-0142.mediawiki
@ -24,14 +24,14 @@ To define standard payment address for native segregated witness (segwit) transa
 The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH).
 The new address is encoded in a way similar to existing address formats:
-  
+
  base58-encode:
    [1-byte address version]
    [1-byte witness program version]
    [0x00]
    [20/32-byte-hash]
    [4-byte checksum]
-  
+
 For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address.
 For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address.
@ -123,25 +123,25 @@ This proposal is forward-compatible with future versions of witness programs of
 == Example ==
 The following public key,
-  
+
    0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
- 
+
 when encoded as a P2PKH template, would become:
-  
+
    DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
 With the corresponding version 1 Bitcoin address being:
-  
+
    16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
- 
+
-When the same public key is encoded as P2WPKH, the scriptPubKey becomes: 
+When the same public key is encoded as P2WPKH, the scriptPubKey becomes:
-  
+
    OP_0 <010966776006953D5567439E5E39F86A0D273BEE>
 Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is:
-  
+
    p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm
- 
+
 == Reference implementation ==
 https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@ -31,7 +31,7 @@ A new transaction digest algorithm is defined, but only applicable to sigops in
     1. nVersion of the transaction (4-byte little endian)
     2. hashPrevouts (32-byte hash)
     3. hashSequence (32-byte hash)
-     4. outpoint (32-byte hash + 4-byte little endian) 
+     4. outpoint (32-byte hash + 4-byte little endian)
     5. scriptCode of the input (serialized as scripts inside CTxOuts)
     6. value of the output spent by this input (8-byte little endian)
     7. nSequence of the input (4-byte little endian)
@ -77,7 +77,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
  uint256 hashPrevouts;
  uint256 hashSequence;
  uint256 hashOutputs;
-  
+
  if (!(nHashType & SIGHASH_ANYONECANPAY)) {
      CHashWriter ss(SER_GETHASH, 0);
      for (unsigned int n = 0; n < txTo.vin.size(); n++) {
@ -85,7 +85,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
      }
      hashPrevouts = ss.GetHash();
  }
-  
+
  if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
      CHashWriter ss(SER_GETHASH, 0);
      for (unsigned int n = 0; n < txTo.vin.size(); n++) {
@ -93,7 +93,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
      }
      hashSequence = ss.GetHash();
  }
-  
+
  if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
      CHashWriter ss(SER_GETHASH, 0);
      for (unsigned int n = 0; n < txTo.vout.size(); n++) {
@ -105,7 +105,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
      ss << txTo.vout[nIn];
      hashOutputs = ss.GetHash();
  }
-  
+
  CHashWriter ss(SER_GETHASH, 0);
  // Version
  ss << txTo.nVersion;
@ -114,7 +114,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
  ss << hashSequence;
  // The input being signed (replacing the scriptSig with scriptCode + amount)
  // The prevout may already be contained in hashPrevout, and the nSequence
-  // may already be contain in hashSequence.
+  // may already be contained in hashSequence.
  ss << txTo.vin[nIn].prevout;
  ss << static_cast<const CScriptBase&>(scriptCode);
  ss << amount;
@ -125,7 +125,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
  ss << txTo.nLockTime;
  // Sighash type
  ss << nHashType;
-  
+
  return ss.GetHash();
 </source>
@ -139,42 +139,42 @@ Since this policy is preparation for a future softfork proposal, to avoid potent
 To ensure consistency in consensus-critical behaviour, developers should test their implementations against all the tests below. More tests related to this proposal could be found under https://github.com/bitcoin/bitcoin/tree/master/src/test/data .
 === Native P2WPKH ===
-  
+
  The following is an unsigned transaction:
    0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000
-    
+
    nVersion:  01000000
    txin:      02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff
                  ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff
    txout:     02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
                  9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
    nLockTime: 11000000
-  
+
  The first input comes from an ordinary P2PK:
    scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25
    private key  : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866
-    
+
  The second input comes from a P2WPKH witness program:
    scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6
    private key  : 619c335025c7f4012e556c2a58b2506e30b8511b53ade95ea316fd8c3286feb9
    public key   : 025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357
-    
+
  To sign it with a nHashType of 1 (SIGHASH_ALL):
-  
+
  hashPrevouts:
    dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000)
  = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
-  
+
  hashSequence:
    dSHA256(eeffffffffffffff)
  = 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
-  
+
  hashOutputs:
    dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac)
  = 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
-  
+
  hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000
-  
+
    nVersion:     01000000
    hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
    hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
@ -185,12 +185,12 @@ To ensure consistency in consensus-critical behaviour, developers should test th
    hashOutputs:  863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
    nLockTime:    11000000
    nHashType:    01000000
-    
+
  sigHash:      c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670
  signature:    304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01
-    
+
  The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000
-  
+
    nVersion:  01000000
    marker:    00
    flag:      01
@ -203,38 +203,38 @@ To ensure consistency in consensus-critical behaviour, developers should test th
    nLockTime: 11000000
 === P2SH-P2WPKH ===
-  
+
-  
+
  The following is an unsigned transaction: 0100000001db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a54770100000000feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac92040000
-  
+
    nVersion:  01000000
    txin:      01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 00 feffffff
    txout:     02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac
                  0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac
    nLockTime: 92040000
-  
+
  The input comes from a P2SH-P2WPKH witness program:
    scriptPubKey : a9144733f37cf4db86fbc2efed2500b4f4e49f31202387, value: 10
    redeemScript : 001479091972186c449eb1ded22b78e40d009bdf0089
    private key  : eb696a065ef48a2192da5b28b694f87544b30fae8327c4510137a922f32c6dcf
    public key   : 03ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873
-  
+
  To sign it with a nHashType of 1 (SIGHASH_ALL):
-  
+
  hashPrevouts:
    dSHA256(db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000)
  = b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a
-  
+
  hashSequence:
    dSHA256(feffffff)
  = 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198
-  
+
  hashOutputs:
    dSHA256(b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac)
  = de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83
-  
+
  hash preimage: 01000000b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001976a91479091972186c449eb1ded22b78e40d009bdf008988ac00ca9a3b00000000feffffffde984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c839204000001000000
-  
+
    nVersion:     01000000
    hashPrevouts: b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a
    hashSequence: 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198
@ -245,10 +245,10 @@ To ensure consistency in consensus-critical behaviour, developers should test th
    hashOutputs:  de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83
    nLockTime:    92040000
    nHashType:    01000000
-  
+
  sigHash:      64f3b0f4dd2bb3aa1ce8566d220cc74dda9df97d8490cc81d89d735c92e59fb6
  signature:    3044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01
-  
+
  The serialized signed transaction is: 01000000000101db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001716001479091972186c449eb1ded22b78e40d009bdf0089feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac02473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb012103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a2687392040000
    nVersion:  01000000
    marker:    00
@ -263,33 +263,33 @@ To ensure consistency in consensus-critical behaviour, developers should test th
 This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGHASH_SINGLE</code> are processed:
-  
+
-  
+
  The following is an unsigned transaction:
    0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000
-  
+
    nVersion:  01000000
    txin:      02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff
                  0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff
    txout:     01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac
    nLockTime: 00000000
-  
+
  The first input comes from an ordinary P2PK:
    scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625
    private key:  b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c
    signature:    304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL)
-  
+
  The second input comes from a native P2WSH witness program:
    scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49
    witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
                   <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG
-  
+
  To sign it with a nHashType of 3 (SIGHASH_SINGLE):
-  
+
  hashPrevouts:
    dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000)
  = ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
-  
+
    nVersion:     01000000
    hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
    hashSequence: 0000000000000000000000000000000000000000000000000000000000000000
@ -300,7 +300,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH
    hashOutputs:  0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output)
    nLockTime:    00000000
    nHashType:    03000000
-  
+
  scriptCode:  4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
                                                                                       ^^
               (please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode)
@ -309,7 +309,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH
  public key:  026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae
  private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd
  signature:   3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
-  
+
  scriptCode:  23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
               (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
  preimage:    01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
@ -317,36 +317,36 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH
  public key:  0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465
  private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec
  signature:   304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
-  
+
  The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000
 This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, and <code>SINGLE|ANYONECANPAY</code> does not commit to the input index:
-  
+
-  
+
  The following is an unsigned transaction:
    0100000002e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac00000000
-  
+
    nVersion:  01000000
    txin:      02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff
                  80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff
    txout:     02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac
                  8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac
    nLockTime: 00000000
-  
+
  The first input comes from a native P2WSH witness program:
    scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215
    witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
                  0 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
-  
+
  The second input comes from a native P2WSH witness program:
    scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215
    witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
                  1 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
-  
+
  To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY):
-  
+
    nVersion:     01000000
    hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
    hashSequence: 0000000000000000000000000000000000000000000000000000000000000000
@ -357,7 +357,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
    hashOutputs:  (see below)
    nLockTime:    00000000
    nHashType:    83000000
-  
+
  outpoint:    e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000
  scriptCode:  270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
               (since the OP_CODESEPARATOR is not executed, nothing is removed from the scriptCode)
@ -367,7 +367,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
  public key:  0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98
  private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d
  signature:   3045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683
-  
+
  outpoint:    80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000
  scriptCode:  2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
               (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
@ -377,7 +377,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
  public key:  0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98
  private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d
  signature:   30440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83
-  
+
  The serialized signed transaction is:
  01000000000102e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000
    nVersion:  01000000
@ -390,7 +390,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
    witness    02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
               02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
    nLockTime: 00000000
-  
+
  Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped:
  0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000
    nVersion:  01000000
@ -408,37 +408,37 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
 This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different <code>SIGHASH</code> types.
-  
+
-  
+
  The following is an unsigned transaction: 010000000136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000000ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac00000000
-  
+
    nVersion:  01000000
    txin:      01 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e 01000000 00 ffffffff
    txout:     02 00e9a43500000000 1976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac
                  c0832f0500000000 1976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac
    nLockTime: 00000000
-  
+
  The input comes from a P2SH-P2WSH 6-of-6 multisig witness program:
    scriptPubKey : a9149993a429037b5d912407a71c252019287b8d27a587, value: 9.87654321
    redeemScript : 0020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54
    witnessScript: 56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae
-  
+
  hashPrevouts:
    dSHA256(36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000)
  = 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
-  
+
  hashSequence:
    dSHA256(ffffffff)
  = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
-  
+
  hashOutputs for ALL:
    dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac)
  = bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc
-  
+
  hashOutputs for SINGLE:
    dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac)
  = 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708
-  
+
  hash preimage for ALL: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa03bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504436641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000001000000
    nVersion:     01000000
    hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
@ -454,7 +454,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
  public key:   0307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba3
  private key:  730fff80e1413068a05b57d6a58261f07551163369787f349438ea38ca80fac6
  signature:    304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01
-  
+
  hash preimage for NONE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000002000000
    nVersion:     01000000
    hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
@ -470,7 +470,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
  public key:     03b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b
  private key:    11fa3d25a17cbc22b29c44a484ba552b5a53149d106d3d853e22fdd05a2d8bb3
  signature:      3044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502
-  
+
  hash preimage for SINGLE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000003000000
    nVersion:     01000000
    hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
@ -486,7 +486,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
  public key:     034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a
  private key:    77bf4141a87d55bdd7f3cd0bdccf6e9e642935fec45f2f30047be7b799120661
  signature:      3044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403
-  
+
  hash preimage for ALL|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000081000000
    nVersion:     01000000
    hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
@ -502,7 +502,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
  public key:     033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f4
  private key:    14af36970f5025ea3e8b5542c0f8ebe7763e674838d08808896b63c3351ffe49
  signature:      3045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381
-  
+
  hash preimage for NONE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000082000000
    nVersion:     01000000
    hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
@ -518,7 +518,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
  public key:     03a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac16
  private key:    fe9a95c19eef81dde2b95c1284ef39be497d128e2aa46916fb02d552485e0323
  signature:      3045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a0882
-  
+
  hash preimage for SINGLE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000083000000
    nVersion:     01000000
    hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
@ -534,7 +534,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
  public key:     02d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b
  private key:    428a7aee9f0c2af0cd19af3cf1c78149951ea528726989b2e83e4778d2c3f890
  signature:      30440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783
-  
+
  The serialized signed transaction is: 0100000000010136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000023220020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac080047304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01473044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502473044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403483045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381483045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a08824730440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae00000000
@ -542,35 +542,35 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
 These examples show that <code>FindAndDelete</code> for the signature is not applied. The transactions are generated in an unconventional way. Instead of signing using a private key, the signatures are pre-determined as part of <code>witnessScript</code>. The public keys are generated with key recovery, using the fixed signatures and the <code>sighash</code> defined in this proposal. Therefore, the private keys are unknown.
-  
+
  The following is an unsigned transaction: 010000000169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff0101000000000000000000000000
-  
+
    nVersion:  01000000
    txin:      01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff
    txout:     01 0100000000000000 00
    nLockTime: 00000000
-  
+
  The input comes from a P2WSH witness program:
    scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 0.00200000
    redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01>
                   ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
-  
+
  To sign it with a nHashType of 1 (SIGHASH_ALL):
-  
+
  hashPrevouts:
    dSHA256(69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000)
  = b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f
-  
+
  hashSequence:
    dSHA256(ffffffff)
  = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
-  
+
  hashOutputs:
    dSHA256(010000000000000000)
  = e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228
-  
+
  hash preimage: 01000000b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504469c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d00004aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000
-  
+
    nVersion:     01000000
    hashPrevouts: b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f
    hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
@ -581,11 +581,11 @@ These examples show that <code>FindAndDelete</code> for the signature is not app
    hashOutputs:  e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228
    nLockTime:    00000000
    nHashType:    01000000
-  
+
  sigHash:      71c9cd9b2869b9c70b01b1f0360c148f42dee72297db312638df136f43311f23
  signature:    30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01
  pubkey:       02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c
-  
+
  The serialized signed transaction is: 0100000000010169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff01010000000000000000034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000
    nVersion:  01000000
@ -597,11 +597,11 @@ These examples show that <code>FindAndDelete</code> for the signature is not app
                  2102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c
                  4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
    nLockTime: 00000000
-  
+
  The following transaction is a <code>OP_CHECKMULTISIGVERIFY</code> version of the <code>FindAndDelete</code> examples: 010000000001019275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d000000ffffffff0101000000000000000007004830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960101022102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c021034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c039596017500000000
-  
+
  redeemScript:  OP_2 OP_CHECKMULTISIGVERIFY <30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> <304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601>
  hash preimage: 0100000039283953eb1e26994dde57b7f9362a79a8c523e2f8deba943c27e826a005f1e63bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d00009552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000
  sighash:       c1628a1e7c67f14ca0c27c06e4fdeec2e6d1a73c7a91d7c046ff83e835aebb72
@ -618,7 +618,7 @@ The new serialization format is described in BIP144 <ref>[[bip-0144.mediawiki|BI
 == Deployment ==
-This proposal is deployed with Segregated Witness softfork (BIP 141) 
+This proposal is deployed with Segregated Witness softfork (BIP 141)
 == Backward compatibility ==
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@ -79,7 +79,7 @@ The serialization has the following structure:
 Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.
-If the witness is empty, the old serialization format must be used. 
+If the witness is empty, the old serialization format must be used.
 Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins.
--- a/bip-0150.mediawiki
+++ b/bip-0150.mediawiki
@ -5,7 +5,7 @@
  Author: Jonas Schnelli <dev@jonasschnelli.ch>
  Comments-Summary: Discouraged for implementation (one person)
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0150
-  Status: Draft
+  Status: Deferred
  Type: Standards Track
  Created: 2016-03-23
  License: PD
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@ -209,7 +209,7 @@ There are several design goals for the Short ID calculation:
 * '''Space''' cmpctblock messages are never optional in this protocol, and contain a short ID for each non-prefilled transaction in the block. Thus, the size of short IDs is directly proportional to the maximum bandwidth savings possible.
 * '''Collision resistance''' It should be hard for network participants to create transactions that cause collisions. If an attacker were able to cause such collisions, filling mempools (and, thus, blocks) with them would cause poor network propagation of new (or non-attacker, in the case of a miner) blocks.
-SipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisons, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior.
+SipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisions, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior.
 ====Random collision probability====
--- a/bip-0154.mediawiki
+++ b/bip-0154.mediawiki
@ -71,7 +71,7 @@ solve the challenge and reconnect, or discard it and find a different peer (or w
 There are two POW identifiers currently. When a new identifier is introduced, it should be added with an increment of 1
 to the last identifier in the list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should
-retain its place in the list indefinitely. 
+retain its place in the list indefinitely.
 {|class="wikitable"
 ! ID !! Algorithm Name !! Work !! Param size !! Solution size !! Provably Secure !! SPH Resistance !! Status
@ -173,7 +173,7 @@ Additional notes:
 There is only one Purpose Identifier currently. In the future, more Purpose Identifiers could be added for at-DoS-risk operations,
 such as bloom filters. When a new identifier is introduced, it should be added with an increment of 1 to the last identifier in the
 list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should retain its place in
-the list indefinitely. 
+the list indefinitely.
 {|class="wikitable"
 ! ID !! Purpose Name !! Description !! Status
@ -236,7 +236,7 @@ Normally mid-layer (all but the last) POW algorithms have a zero-length input. E
 |-
 | 1..4 || pow-id || 1 || sha256
 |-
-| 5 || pow-params (config_length) || 9 || 
+| 5 || pow-params (config_length) || 9 ||
 |-
 | 6..9 || pow-params (target) || 0x207fffff || Resulting hash must be <= the compact hash 0x207fffff*
 |-
@ -248,7 +248,7 @@ Normally mid-layer (all but the last) POW algorithms have a zero-length input. E
 |-
 | 19..22 || pow-id || 2 || cuckoo-cycle
 |-
-| 23 || pow-params (config_length) || 8 || 
+| 23 || pow-params (config_length) || 8 ||
 |-
 | 24 || pow-params (sizeshift) || 28
 |-
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@ -44,7 +44,7 @@ interpreted as described in RFC 2119<ref>[https://tools.ietf.org/html/rfc2119 RF
 The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>.
 It is serialized in the standard encoding for P2P messages.
-Its format is similar to the current <code>addr</code> message format, with the difference that the 
+Its format is similar to the current <code>addr</code> message format, with the difference that the
 fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize].
 This means that the message contains a serialized <code>std::vector</code> of the following structure:
--- a/bip-0156.mediawiki
+++ b/bip-0156.mediawiki
@ -109,7 +109,7 @@ Figure 3
 To avoid this issue, we suggest "per-inbound-edge" routing. Each inbound peer is
 assigned a particular Dandelion destination. Each Dandelion transaction that
-arrives via this peer is forwarded to the same Dandelion destination. 
+arrives via this peer is forwarded to the same Dandelion destination.
 Per-inbound-edge routing breaks the described attack by blocking an adversary's
 ability to construct useful fingerprints. Fingerprints arise when routing
 decisions are made independently per transaction at each node. In this case, two
--- a/bip-0157.mediawiki
+++ b/bip-0157.mediawiki
@ -396,7 +396,7 @@ Once the client has downloaded and verified all filter headers needed, ''and''
 no outbound peers have sent conflicting headers, the client can download the
 actual block filters it needs. The client MAY backfill filter headers before the
 first verified one at this point if it only downloaded them starting at a later
-point. Clients SHOULD persist the verified filter headers for last 100 blocks in
+point. Clients SHOULD persist the verified filter headers for the last 100 blocks in
 the chain (or whatever finality depth is desired), to compare against headers
 received from new peers after restart. They MAY store more filter headers to
 avoid redownloading them if a rescan is later necessary.
--- a/bip-0158.mediawiki
+++ b/bip-0158.mediawiki
@ -82,7 +82,7 @@ one is able to select both Parameters independently, then more optimal values
 can be
 selected<ref>https://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845</ref>.
 Set membership queries against the hash outputs will have a false positive rate
-of <code>M</code>. To avoid integer overflow, the number of items <code>N</code>
+of <code>1 / M</code>. To avoid integer overflow, the number of items <code>N</code>
 MUST be <2^32 and <code>M</code> MUST be <2^32.
 The items are first passed through the pseudorandom function ''SipHash'', which
@ -186,7 +186,7 @@ golomb_decode(stream, P: uint) -> uint64:
 A GCS is constructed from four parameters:
 * <code>L</code>, a vector of <code>N</code> raw items
 * <code>P</code>, the bit parameter of the Golomb-Rice coding
-* <code>M</code>, the target false positive rate
+* <code>M</code>, the inverse of the target false positive rate
 * <code>k</code>, the 128-bit key used to randomize the SipHash outputs
 The result is a byte vector with a minimum size of <code>N * (P + 1)</code>
@ -344,7 +344,7 @@ Light client: [https://github.com/lightninglabs/neutrino]
 Full-node indexing: https://github.com/Roasbeef/btcd/tree/segwit-cbf
-Golomb-Rice Coded sets: https://github.com/btcsuite/btcutil/blob/master/gcs
+Golomb-Rice Coded sets: https://github.com/btcsuite/btcd/tree/master/btcutil/gcs
 == Appendix A: Alternatives ==
--- a/bip-0158/gentestvectors.go
+++ b/bip-0158/gentestvectors.go
@ -37,7 +37,7 @@ var (
 		{49291, "Tx pays to empty output script"},
 		{180480, "Tx spends from empty output script"},
 		{926485, "Duplicate pushdata 913bcc2be49cb534c20474c4dee1e9c4c317e7eb"},
-		{987876, "Coinbase tx has unparseable output script"},
+		{987876, "Coinbase tx has unparsable output script"},
 		{1263442, "Includes witness data"},
 		{1414221, "Empty data"},
 	}
@ -223,7 +223,7 @@ func main() {
 		}
 		// We'll now ensure that we've constructed the same filter as
-		// the chain server we're fetching blocks form.
+		// the chain server we're fetching blocks from.
 		filter, err := client.GetCFilter(
 			blockHash, wire.GCSFilterRegular,
 		)
--- a/bip-0159.mediawiki
+++ b/bip-0159.mediawiki
@ -5,7 +5,7 @@
  Author: Jonas Schnelli <dev@jonasschnelli.ch>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159
-  Status: Draft
+  Status: Final
  Type: Standards Track
  Created: 2017-05-11
  License: BSD-2-Clause
@ -50,7 +50,7 @@ Pruned peers following this BIP may consume more outbound bandwidth.
 Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
-== Compatibility == 
+== Compatibility ==
 This proposal is backward compatible.
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@ -171,6 +171,28 @@ The currently defined global types are as follows:
 | 2
 | [[bip-0370.mediawiki|370]]
 |-
 | Silent Payment Global ECDH Share
 | <tt>PSBT_GLOBAL_SP_ECDH_SHARE = 0x07</tt>
 | <tt><33 byte scan key></tt>
 | The scan key that this ECDH share is for.
 | <tt><33 byte share></tt>
 | An ECDH share for a scan key. The ECDH shared is computed with ''a * B_scan'', where ''a'' is the sum of all private keys of all eligible inputs, and ''B_scan'' is the scan key of a recipient.
 |
 | 0
 | 2
 | [[bip-0375.mediawiki|375]]
 |-
 | Silent Payment Global DLEQ Proof
 | <tt>PSBT_GLOBAL_SP_DLEQ = 0x08</tt>
 | <tt><33 byte scan key></tt>
 | The scan key that this proof covers.
 | <tt><64-byte proof></tt>
 | A BIP374 DLEQ proof computed for the matching ECDH share.
 |
 | 0
 | 2
 | [[bip-0375.mediawiki|375]]
 |-
 | PSBT Version Number
 | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
 | None
@ -483,6 +505,74 @@ The currently defined per-input types are defined as follows:
 | 0, 2
 | [[bip-0371.mediawiki|371]]
 |-
 | MuSig2 Participant Public Keys
 | <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a</tt>
 | <33 byte plain aggregate pubkey>
 | The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
 be in the script directly (as x-only). It may instead be a parent public key from which the public keys in the
 script were derived.
 | <tt><33 byte compressed pubkey>*</tt>
 | A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
 required for aggregation. If sorting was done, then the keys must be in the sorted order.
 |
 |
 | 0, 2
 | [[bip-0373.mediawiki|373]]
 |-
 | MuSig2 Public Nonce
 | <tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt>
 | <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
 | The compressed public key of the participant providing this nonce, followed by the plain public
 key the participant is providing the nonce for, followed by the BIP 341 tapleaf hash of
 the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or the
 taproot output key, then the tapleaf hash must be omitted. The plain public key must be
 the key found in the script and not the aggregate public key that it was derived from, if it was
 derived from an aggregate key.
 | <tt><66 byte public nonce></tt>
 | The public nonce produced by the <tt>NonceGen</tt> algorithm.
 |
 |
 | 0, 2
 | [[bip-0373.mediawiki|373]]
 |-
 | MuSig2 Participant Partial Signature
 | <tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt>
 | <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
 | The compressed public key of the participant providing this partial signature, followed by the
 plain public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash
 of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or
 the taproot output key, then the tapleaf hash must be omitted. Note that the plain public key must
 be the key found in the script and not the aggregate public key that it was derived from, if it was
 derived from an aggregate key.
 | <tt><32 byte partial signature></tt>
 | The partial signature produced by the <tt>Sign</tt> algorithm.
 |
 |
 | 0, 2
 | [[bip-0373.mediawiki|373]]
 |-
 | Silent Payment Input ECDH Share
 | <tt>PSBT_IN_SP_ECDH_SHARE = 0x1d</tt>
 | <tt><33 byte scan key></tt>
 | The scan key that this ECDH share is for.
 | <tt><33 byte share></tt>
 | An ECDH share for a scan key. The ECDH shared is computed with ''a * B_scan'', where ''a'' is the private key of the corresponding prevout public key, and ''B_scan'' is the scan key of a recipient.
 |
 | 0
 | 2
 | [[bip-0375.mediawiki|375]]
 |-
 | Silent Payment Input DLEQ Proof
 | <tt>PSBT_IN_SP_DLEQ = 0x1e</tt>
 | <tt><33 byte scan key></tt>
 | The scan key that this proof covers.
 | <tt><64-byte proof></tt>
 | A BIP374 DLEQ proof computed for the matching ECDH share.
 |
 | 0
 | 2
 | [[bip-0375.mediawiki|375]]
 |-
 | Proprietary Use Type
 | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
 | <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>
@ -560,11 +650,11 @@ determine which outputs are change outputs and verify that the change is returni
 | None
 | No key data
 | <tt><bytes script></tt>
-| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2.
+| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2 if not sending to a BIP352 silent payment address, otherwise may be omitted.
-| 2
+|
 | 0
 | 2
-| [[bip-0370.mediawiki|370]]
+| [[bip-0370.mediawiki|370]], [[bip-0375.mediawiki|375]]
 |-
 | Taproot Internal Key
 | <tt>PSBT_OUT_TAP_INTERNAL_KEY = 0x05</tt>
@ -599,6 +689,54 @@ determine which outputs are change outputs and verify that the change is returni
 | 0, 2
 | [[bip-0371.mediawiki|371]]
 |-
 | MuSig2 Participant Public Keys
 | <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
 | <33 byte plain aggregate pubkey>
 | The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
 be in the script directly. It may instead be a parent public key from which the public keys in the
 script were derived.
 | <tt><33 byte compressed pubkey>*</tt>
 | A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
 required for aggregation. If sorting was done, then the keys must be in the sorted order.
 |
 |
 | 0, 2
 | [[bip-0373.mediawiki|373]]
 |-
 | Silent Payment Data
 | <tt>PSBT_OUT_SP_V0_INFO = 0x09</tt>
 | None
 | No key data
 | <tt><33 byte scan key> <33 byte spend key></tt>
 | The scan and spend public keys from the silent payments address.
 |
 | 0
 | 2
 | [[bip-0375.mediawiki|375]]
 |-
 | Silent Payment Label
 | <tt>PSBT_OUT_SP_V0_LABEL = 0x10</tt>
 | None
 | No key data
 | <tt><32-bit little endian uint label></tt>
 | The label to use to compute the spend key of the silent payments address to verify change.
 |
 | 0
 | 2
 | [[bip-0375.mediawiki|375]]
 |-
 | BIP 353 DNSSEC proof
 | <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
 | None
 | No key data
 | <tt><1-byte-length-prefixed BIP 353 human-readable name><RFC 9102-formatted AuthenticationChain DNSSEC Proof></tt>
 | A BIP 353 human-readable name (without the ₿ prefix), prefixed by a 1-byte length.
 Followed by an [[https://www.rfc-editor.org/rfc/rfc9102.html#name-dnssec-authentication-chain|RFC 9102 DNSSEC <tt>AuthenticationChain</tt>]] (i.e. a series of DNS Resource Records in no particular order) providing a DNSSEC proof to a BIP 353 DNS TXT record.
 |
 |
 | 0, 2
 | [[bip-0353.mediawiki|353]]
 |-
 | Proprietary Use Type
 | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
 | <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>
@ -821,7 +959,7 @@ If a field requires significant description as to its usage, it should be accomp
 The field must be added to the field listing tables in the Specification section.
 Although some PSBT version 0 implementations encode types as uint8_t rather than compact size,
 it is still safe to add >0xFD fields to PSBT 0, because these old parsers ignore
-unknown fields, and <keytype> is prefixed by its length. 
+unknown fields, and <keytype> is prefixed by its length.
 ===Procedure For New Versions===
--- a/bip-0176.mediawiki
+++ b/bip-0176.mediawiki
@ -48,7 +48,7 @@ The term "bit" has many different definitions, but the ones of particular note a
 * bit meaning some amount of data (e.g., the first bit of the version field is 0)
 * bit meaning strength of a cryptographic algorithm (e.g., 256-bit ECDSA is used in Bitcoin)
-The first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means. 
+The first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means.
 == Copyright ==
 This BIP is licensed under the BSD 2-clause license.
--- a/bip-0199.mediawiki
+++ b/bip-0199.mediawiki
@ -19,13 +19,13 @@ This BIP describes a script for generalized off-chain contract negotiation.
 ==Summary==
-A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash.  It also permits 
+A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash.  It also permits
 a second party (the "buyer") to spend the funds after a timeout is reached, in a refund situation.
 The script takes the following form:
    OP_IF
-        [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>            
+        [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
    OP_ELSE
        <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
    OP_ENDIF
@ -44,28 +44,28 @@ The script takes the following form:
 ** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR
 ** Victor recovers the funds after the timeout threshold.
-Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage.  Peggy is 
+Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage.  Peggy is
-interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does 
+interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does
 not enter the blockchain before Victor's but does reveal the preimage to Victor anyway.
 ==Motivation==
-In many off-chain protocols, secret disclosure is used as part of a settlement mechanism.  In some others, the secrets themselves are valuable.  HTLC transactions are 
+In many off-chain protocols, secret disclosure is used as part of a settlement mechanism.  In some others, the secrets themselves are valuable.  HTLC transactions are
-a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the 
+a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the
 opportunity that the possessor of a secret has to receive the funds before such a refund can occur.
 ===Lightning network===
 In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels.
-Alice constructs K and hashes it to produce L.  She sends an HTLC payment to Bob for the preimage of L.  Bob sends an HTLC payment to Carol for the same preimage and 
+Alice constructs K and hashes it to produce L.  She sends an HTLC payment to Bob for the preimage of L.  Bob sends an HTLC payment to Carol for the same preimage and
-amount.  Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated.  If 
+amount.  Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated.  If
 at any point some parties become uncooperative, the process can be aborted via the refund conditions.
 ===Zero-knowledge contingent payments===
-Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information.  As an example, a 
+Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information.  As an example, a
-zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution.  (See 
+zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution.  (See
 [https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.)
 HTLC transactions can be used to exchange such decryption keys for money without risk, and they do not require large or expensive-to-validate transactions.
--- a/bip-0300.mediawiki
+++ b/bip-0300.mediawiki
@ -15,31 +15,28 @@
 ==Abstract==
-In Bip300, txns are not signed via cryptographic key. Instead, they are "signed" by hashpower, over time. Like a big multisig, 13150-of-26300, where each block is a new "signature".
+BIP-300 enables a new type of L2, where "withdrawals" (the L2-to-L1 txns) are governed by proof-of-work -- instead of a federation or fixed set of pubkeys.
-Bip300 emphasizes slow, transparent, auditable transactions which are easy for honest users to get right and very hard for dishonest users to abuse. The chief design goal for Bip300 is ''partitioning'' -- users may safely ignore Bip300 txns if they want to (or Bip300 entirely).
+BIP-300 emphasizes slow, transparent, and auditable withdrawals that are easy for honest users to get right and hard for dishonest miners to abuse. The main design goal for BIP-300 is ''partitioning'' -- users can ignore BIP-300 txns if they wish; it makes no difference to L1 if the user validates all, some, or none of them. The second design goal is ''security'' -- users of the L2 should feel confident that, [https://www.drivechain.info/blog/fees/ if the L2 network is paying a lot of fees], then miners will want to keep it around, and the withdrawals will therefore be processed accurately.
-See [http://www.drivechain.info/ this site] for more information.
+Once BIP-300 has established a "bridge" between L1 and these L2s, users can swap coins in and out instantly, only using BIP-300 for final settlement. This setup allows Bitcoin to process all the transactions in the world, of any shape or size, regardless of blocksize, node software, tech stack, or decentralization level -- all without altering L1 at all.
 ==Motivation==
 BIP-300 allows us to achieve [https://www.truthcoin.info/blog/zside-meltcast/ strong privacy], [https://www.truthcoin.info/blog/thunder/ planetary scale], and [https://www.truthcoin.info/blog/all-world-txns/ hundreds of billions of dollars in annual mining revenues], all with a [https://www.drivechain.info/blog/fees/ security model] that is [https://x.com/Truthcoin/status/1701959339508965405 much stronger than] that of the [https://www.truthcoin.info/blog/ln-blackpill/ Lightning Network].
-As Reid Hoffman [https://blockstream.com/2015/01/13/en-reid-hoffman-on-the-future-of-the-bitcoin-ecosystem/ wrote in 2014]: "Sidechains allow developers to add features and functionality to the Bitcoin universe without actually modifying the Bitcoin Core code...Consequently, innovation can occur faster, in more flexible and distributed ways, without losing the synergies of a common platform with a single currency."
+The original motivation stretches back to Reid Hoffman, who [https://blockstream.com/2015/01/13/en-reid-hoffman-on-the-future-of-the-bitcoin-ecosystem/ wrote in 2014]: "Sidechains allow developers to add features and functionality to the Bitcoin universe without actually modifying the Bitcoin Core code...Consequently, innovation can occur faster, in more flexible and distributed ways, without losing the synergies of a common platform with a single currency."
-Today, coins such as Namecoin, Monero, ZCash, and Sia, offer features that Bitcoiners cannot access -- not without selling their BTC to invest in a rival monetary unit. According to [https://coinmarketcap.com/charts/#dominance-percentage coinmarketcap.com], there is now more value *outside* the BTC protocol than within it. According to [https://cryptofees.info/ cryptofees.info], 15x more txn fees are paid outside the BTC protocol, than within it.
+See [http://www.drivechain.info/ drivechain.info] for more information.
 Software improvements to Bitcoin rely on developer consensus -- BTC will pass on a good idea if it is even slightly controversial. Development is slow: we are now averaging one major feature every 5 years.
 Sidechains allow for competitive "benevolent dictators" to create a new sidechain at any time. These dictators are accountable only to their users, and (crucially) they are protected from rival dictators. Users can move their BTC among these different pieces of software, as *they* see fit.
 BTC can copy every useful technology, as soon as it is invented; scamcoins lose their justification and become obsolete; and the community can be pro-creativity, knowing that Layer1 is protected from harmful changes.
 ==Specification==
 ===Overview===
-Bip300 allows for six new blockchain messages (these have consensus significance):
+BIP-300 consists of six new blockchain messages:
 * M1. "Propose New Sidechain"
 * M2. "ACK Proposal"
@ -48,14 +45,15 @@ Bip300 allows for six new blockchain messages (these have consensus significance
 * M5. Deposit  -- a transfer of BTC from-main-to-side
 * M6. Withdrawal -- a transfer of BTC from-side-to-main
 Nodes organize those messages into two caches:
-* D1. "The Sidechain List", which tracks the 256 Hashrate Escrows (Escrows are slots that a sidechain can live in).
+Nodes organize this data into [https://github.com/LayerTwo-Labs/bip300301_enforcer/blob/master/src/bip300.rs#L79-L96 a few caches], mainly these two:
-* D2. "The Withdrawal List", which tracks the withdrawal-Bundles (coins leaving a Sidechain).
+
 * D1. "The Sidechain List"
 * D2. "The Withdrawal List"
 ==== D1 (The Sidechain List) ====
-D1 is a list of active sidechains. D1 is updated via M1 and M2.
+D1 is a list of active sidechains. D1 is populated via M1 and M2. Fields #9 and #10 are updated via M5 and M6.
 {| class="wikitable"
 |- style="font-weight:bold; text-align:center; vertical-align:middle;"
@ -87,12 +85,12 @@ D1 is a list of active sidechains. D1 is updated via M1 and M2.
 | 5
 | Hash1 - tarball hash
 | uint256
-| Intended as the sha256 hash of the tar.gz of the canonical sidechain software. (This is not enforced anywhere by Bip300, and is for human purposes only.)
+| Intended as the sha256 hash of the tar.gz of the canonical sidechain software. (This is not enforced by BIP-300, and is for human purposes only.)
 |- style="vertical-align:middle;"
 | 6
 | Hash2 - git commit hash
 | uint160
-| Intended as the git commit hash of the canonical sidechain node software. (This is not enforced anywhere by Bip300, and is for human purposes only.)
+| Intended as the git commit hash of the canonical sidechain node software. (This is not enforced by BIP-300, and is for human purposes only.)
 |-
 | 7
 | Active
@ -118,17 +116,17 @@ D1 is a list of active sidechains. D1 is updated via M1 and M2.
 ==== D2 (The Withdrawal List) ====
-D2 lists withdrawal-attempts. If these attempts succeed, they will pay coins "from" a Bip300-locked UTXO, to new UTXOs controlled by the withdrawing-user. Each attempt pays out many users, so we call these withdrawal-attempts "Bundles".
+Withdrawals are transactions that remove coins "from" L2 (i.e., from the BIP-300 locked UTXO), and place them back on L1. Each BIP-300 withdrawal can pay out up to 6,000 withdrawals, and only one withdrawal can succeed at a time (per L2). Therefore, since all L2 users share the same large withdrawal-event, on L1 we call these withdrawals "bundles".
 D2 is driven by M3, M4, M5, and M6. Those messages enforce the following principles:
-# The Bundles have a canonical order (first come first serve).
+# The database has a canonical order (first come first serve).
 # From one block to the next, every "Blocks Remaining" field decreases by 1.
-# When "Blocks Remaining" reaches zero the Bundle is removed.
+# When "Blocks Remaining" reaches zero, the bundle is removed.
 # From one block to the next, the value in "ACKs" may either increase or decrease, by a maximum of 1 (see M4).
-# If a Bundle's "ACKs" reach 13150 or greater, it "succeeds" and its corresponding M6 message can be included in a block.
+# If a bundle's "ACKs" reach 13150 or greater, it "succeeds" and its corresponding M6 message can be included in a block.
-# If the M6 of a Bundle is paid out, it is also removed.
+# If the M6 of a bundle is paid out, it is also removed.
-# If a Bundle cannot possibly succeed ( 13150 - "ACKs"  >  "Blocks Remaining" ), it is removed immediately.
+# If a bundle cannot possibly succeed ( 13150 - "ACKs"  >  "Blocks Remaining" ), it is removed immediately.
 {| class="wikitable"
@ -145,7 +143,7 @@ D2 is driven by M3, M4, M5, and M6. Those messages enforce the following princip
 | 2
 | Bundle Hash
 | uint256
-| A withdrawal attempt. Specifically, it is a "blinded transaction id" (ie, the double-Sha256 of a txn that has had two fields zeroed out, see M6) of a txn which could withdraw funds from a sidechain.
+| A withdrawal attempt. Specifically, it is a "blinded transaction id" (i.e., the double-Sha256 of a txn that has had two fields zeroed out, see M6) of a txn which could withdraw funds from a sidechain.
 |-
 | 3
 | Work Score (ACKs)
@ -158,20 +156,12 @@ D2 is driven by M3, M4, M5, and M6. Those messages enforce the following princip
 | How long this bundle has left to live (measured in blocks). Starts at 26,300 and counts down.
 |}
 D1, with all 256 slots active, reaches a maximum size of: 256 * ( 1 (map index) + 36 (outpoint) + 8 (amount) ) = 11,520 bytes.
 D2, under normal conditions, would reach a size of: (38 bytes per withdrawal * 256 sidechains) = 9,728 bytes.
 It is possible to spam D2. A miner can add the max M3s (256) every block, forever. This costs 9,728 on-chain bytes per block, an opportunity cost of about 43 txns. It results in no benefit to the miner whatsoever. D2 will eventually hit a ceiling at 124.5568 MB. (By comparison, the Bitcoin UTXO set is about 7,000 MB.) When the attacker stops, D2 will eventually shrink back down to 9,728 bytes.
 === The Six New Bip300 Messages ===
-First, how are new sidechains created?
+=== M1 -- Propose Sidechain ===
-They are first proposed (with M1), and later acked (with M2). This process resembles Bip9 soft fork activation.
+New sidechains are proposed with M1, and ACKed with M2.
 ==== M1 -- Propose Sidechain ====
 M1 is a coinbase OP Return output containing the following:
@ -197,7 +187,7 @@ Otherwise:
 * A new entry is added to D1, whose initial Activation Status is (age=0, fails=0).
-==== M2 -- ACK Sidechain Proposal ====
+=== M2 -- ACK Sidechain Proposal ===
 M2 is a coinbase OP Return output containing the following:
@ -213,52 +203,38 @@ M2 is invalid if:
 * An M2 is already in this block.
 * It tries to ACK two different M1s for the same slot.
-Otherwise: 
+Otherwise:
 * The sidechain is "ACK"ed and does NOT get a "fail" for this block. (As it otherwise would.)
 A sidechain fails to activate if:
-* If the slot is unused: during the next 2016 blocks, it accumulates 201 fails. (Ie, 90% threshold).
+* If the slot is unused: during the next 2016 blocks, it accumulates 1008 fails (i.e., 50% hashrate threshold).
-* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% threshold).
+* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails (i.e., 50% hashrate threshold).
-( Thus we can overwrite a used sidechain slot. Bip300 sidechains are already vulnerable to one catastrophe per 13150 blocks (the invalid withdrawal) so this slot-overwrite option does not change the security assumptions. )
+( Thus we can overwrite a used sidechain slot. BIP-300 sidechains are already vulnerable to one catastrophe per 13150 blocks (the invalid withdrawal), so this slot-overwrite option does not change the security assumptions. )
 Otherwise, the sidechain activates (Active is set to TRUE).
-In the block in which the sidechain activates, the coinbase MUST include at least one 0-valued OP_DRIVECHAIN output. This output becomes the initial CTIP for the sidechain.
+
 === Withdrawing in Bundles ===
 Sidechain withdrawals take the form of "bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare L1 transaction.
 On the L2 side, individual withdrawal requests are periodically combined into a single CoinJoin-like withdrawal bundle. This bundle is hashed [https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L374C1-L419C2 in a particular way] (on both L2 and L1) -- this "blinded hash" commits to its own L1 fee, but (notably) it does not commit to its first tx-input (in that way, it is like [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki BIP-118]).
 This hash is what L1 miners will slowly ACK over 3-6 months, not the M6 itself (nor any sidechain data, of course).
 A bundle will either pay all its withdrawals out (via M6), or fail (and pay nothing out for anyone).
-
+=== M3 -- Propose Bundle ===
 ==== Notes on Withdrawing Coins ====
 Bip300 withdrawals ("M6") are very significant.
 For an M6 to be valid, it must be first "prepped" by one M3 and then 13,150+ M4s. M3 and M4 are about "Bundles".
 ===== What are Bundles? =====
 Sidechain withdrawals take the form of "Bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction.
 Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle.
 This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course). 
 A bundle either pays all its withdrawals out (via M6), or else it fails (and pays nothing out).
 ===== Bundle Hash = Blinded TxID of M6 =====
 The Bundle hash is static as it is being ACKed. Unfortunately, the M6 TxID will be constantly changing -- as users deposit to the sidechain, the input to M6 will change.
 To solve this problem, we do something conceptually similar to AnyPrevOut (BIP 118). We define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. These are: the first input and the first output. Via the former, a sidechain can accept deposits, even if we are acking a TxID that spends from it later. Via the latter, we can force all of the non-withdrawn coins to be returned to the sidechain (even if we don't yet know how many coins this will be).
 ==== M3 -- Propose Bundle ====
 M3 is a coinbase OP Return output containing the following:
    1-byte - OP_RETURN (0x6a)
    4-byte - Commitment header (0xD45AA943)
-    32-byte - The Bundle hash, to populate a new D2 entry
+    32-byte - The bundle hash, to populate a new D2 entry
    1-byte - nSidechain (the slot number)
 M3 is ignored if it does not parse, or if it is for a sidechain that doesn't exist.
@ -272,9 +248,10 @@ M3 is invalid if:
 Otherwise: M3 adds an entry to D2, with initial ACK score = 1 and initial Blocks Remaining = 26,299. (Merely being added to D2, does count as your first upvote.)
 Once a Bundle is in D2, how can we give it enough ACKs to make it valid?
-==== M4 -- ACK Bundle(s) ====
+=== M4 -- ACK Bundle(s) ===
 Once a bundle is in D2, how can we give it enough ACKs to make it valid?
 M4 is a coinbase OP Return output containing the following:
@ -283,37 +260,27 @@ M4 is a coinbase OP Return output containing the following:
    1-byte - Version
    n-byte - The "upvote vector" -- describes which bundle-choice is "upvoted", for each sidechain.
 The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted". 
 For example: if there are two sidechains, and we wish to upvote the 7th bundle on sidechain #1 plus the 4th bundle on sidechain #2, then the upvote vector would be { 07, 04 }. And M4 would be [0x6A,D77D1776,00,0006,0003].
 The version number allows us to shrink the upvote vector in many cases.
 Version 0x00 omits the upvote vector entirely (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4.
 Version 0x01 uses one byte per sidechain, and can be used while all ACKed withdrawals have an index under 256 (ie, 99.99%+ of the time).
 Version 0x02 uses a full two bytes per sidechain (each encoded in little endian), but it always works no matter how many withdrawal proposals exist.
 Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes.
 If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed.
 For example, an upvote vector of { 2 , N/A, 1 } would be represented as [0x6A,D77D1776,01,01,00]. It means: "upvote the second bundle in sidechain #1; and the first bundle in sidechain #3" (iff sidechains #2 has no bundles proposed).
 An upvote vector of { N/A, N/A, 4 } would be [0x6A,D77D1776,01,03].
 The M4 message will be invalid (and invalidate the block), if:
-*  It tries to upvote a Bundle that doesn't exist. (For example, trying to upvote the 7th bundle on sidechain #2, when sidechain #2 has only three bundles.)
+* It tries to upvote a bundle that doesn't exist. (For example, trying to upvote the 7th bundle on sidechain #2, when sidechain #2 has only three bundles.)
-* There are no Bundles at all, from any sidechain.
+* There are no bundles at all, from any sidechain.
-If M4 is NOT present in a block, then it is treated as "abstain".
+If M4 is NOT present in a block, then it is treated as an "abstain" for all sidechains.
 If M4 is present and valid: each withdrawal-bundle that is ACKed, will gain one upvote.
-Important: Within a sidechain-group, upvoting one Bundle ("+1") automatically downvotes ("-1") all other Bundles in that group. However, the minimum ACK-counter is zero. While only one Bundle can be upvoted at once; the whole group can all be unchanged at once ("abstain"), and they can all be downvoted at once ("alarm").
+Each sidechain always has two "virtual bundles" -- an "abstain" bundle (0xFF), and an "alarm" bundle (0xFE). Abstain leaves the ACK count unchanged, and alarm reduces all ACK counts of all bundles by 1.
-For example:
+Any bundle which fails to receive a vote, is downvoted (and loses 1 ACK). If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed.
-{| class="wikitable" 
+
 ==== Examples ====
 To upvote the 7th bundle on sidechain #1, and upvote the 4th bundle on sidechain #2, the upvote vector would be { 07, 04 }. And M4 would be [0x6A,D77D1776,00,0006,0003].
 If block 900,000 has D2 of...
 {| class="wikitable"
 |-
 ! SC#
 ! Bundle Hash
@ -347,10 +314,10 @@ For example:
 |}
-...in block 900,000 could become...
+...and then D2 wants to become:
-{| class="wikitable" 
+{| class="wikitable"
 |-
 ! SC#
 ! Bundle Hash
@ -383,18 +350,29 @@ For example:
 | 22,559
 |}
-...if M4 were [0x6A,D77D1776,00,0000,0001].
+... then M4 would have been [0x6A,D77D1776,00,0000,0001].
 ==== Saving Space ====
 The version number allows us to shrink the upvote vector in many cases.
 Version 0x00 omits the upvote vector entirely (i.e., 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4.
 Version 0x01 uses 1 byte per sidechain, and can be used while all ACKed withdrawals have an index <256 (i.e., 99.99%+ of the time).
 Version 0x02 uses 2 bytes per sidechain, but it always works, even in astronomically unlikely cases (such as when >1 sidechains have >256 bundle candidates).
 Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes.
 For example, an upvote vector of { 2 , N/A, 1 } would be represented as [0x6A,D77D1776,01,01,00]. It means: "upvote the second bundle in sidechain #1; and the first bundle in sidechain #3" (iff sidechains #2 has no bundles proposed).
 An upvote vector of { N/A, N/A, 4 } would be [0x6A,D77D1776,01,03].
 Finally, we describe Deposits and Withdrawals.
-==== M5 -- Deposit BTC to Sidechain ====
+=== M5 -- Deposit BTC (from L1 to L2) ===
-Each sidechain stores all its BTC in one UTXO, called the "CTIP".
+Finally, we describe Deposits (M5) and Withdrawals (M6). These are not coinbase outputs, they are txns on L1.
-By definition, an M5 is a transaction which spends the CTIP and '''increases''' the quantity of coins. An M6 is a transaction which spends the CTIP and '''decreases''' the quantity of coins in the CTIP. See [https://github.com/LayerTwo-Labs/mainchain/blob/391ab390adaa19f92871d769f8e120ca62c1cf14/src/validation.cpp#L688-L801 here].
+We call a transaction "M5" if it spends from the escrow output and '''increases''' the quantity of coins. Conversely, we call a transaction "M6" if it spends from the escrow output and '''decreases''' the quantity of coins. See [https://github.com/LayerTwo-Labs/bip300301_enforcer/blob/master/src/bip300.rs#L462C1-L462C47 here].
-Every time a deposit/withdrawal is made, the old CTIP is spent and a new one is created. (Deposits/Withdrawals never cause UTXO bloat.) At all times, the CTIP of each sidechain is cached in D1 (above).
+Every time a deposit/withdrawal is made, the old UTXO is spent and a single new UTXO is created. (Deposits/Withdrawals never cause UTXO bloat.) At all times, the specific treasury UTXO ("CTIP") of each sidechain is cached in D1 (above).
 Every M5 is valid, as long as:
@ -402,19 +380,18 @@ Every M5 is valid, as long as:
 * The new CTIP has '''more''' coins in it, than before.
-==== M6 -- Withdraw BTC from a Sidechain ====
+=== M6 -- Withdraw BTC (from L2 to L1) ===
 We come, finally, to the critical matter: where users can take their money *out* of the sidechain.
 M6 is invalid if:
-* The blinded hash of M6 does NOT match one of the approved Bundle-hashes.  (In other words: M6 must first be approved by 13,150 upvotes.)
+* The blinded hash of M6 does NOT match one of the approved bundle-hashes.  (In other words: M6 must first be approved by 13,150 upvotes.)
 * The first output of M6 is NOT an OP_DRIVECHAIN. (This OP_DRIVECHAIN becomes the new CTIP. In other words: all non-withdrawn coins are paid back to the sidechain.)
 * The second output is NOT a zero-value OP_RETURN script of exactly 10 bytes, of which 8 bytes are a serialized Bitcoin amount.
 * The txn fee of M6 is NOT exactly equal to the amount of the previous bullet point.
 * There are additional OP_DRIVECHAIN outputs after the first one.
-Else, M6 is valid. 
+Else, M6 is valid -- and the funds are withdrawn.
 (The point of the latter two bullet points, is to allow the bundle hash to cover the L1 transaction fee.)
@ -429,7 +406,9 @@ without it, sidechain numbers 0 and 128 would cause the legacy script interprete
 If an OP_DRIVECHAIN input is spent, the additional rules for M5 or M6 (see above) must be enforced.
-====Weight adjustments====
+<!--
 Weight adjustments
 To account for the additional drivechain checks, each message adds to the block's weight:
@ -449,7 +428,7 @@ To account for the additional drivechain checks, each message adds to the block'
 | M6 || 352
 |}
-<!--
+
 get: 168 WU for 1 byte
 delete: free?
 create: 168 WU for 33 bytes
@ -476,35 +455,25 @@ M5/M6 OP_DRIVECHAIN spends require 2 additional input lookups
 -->
 ==Backward compatibility==
-As a soft fork, older software will continue to operate without modification. Non-upgraded nodes will see a number of phenomena that they don't understand -- coinbase txns with non-txn data, value accumulating in anyone-can-spend UTXOs for months at a time, and then random amounts leaving these UTXOs in single, infrequent bursts. However, these phenomena don't affect them, or the validity of the money that they receive.
+This soft fork can be deployed without modifying Bitcoin Core at all (i.e., via [https://bip300cusf.com/ CUSF]).
 ( As a nice bonus, note that the sidechains themselves inherit a resistance to hard forks. The only way to guarantee that all different sidechain-nodes will always report the same Bundle, is to upgrade sidechains via soft forks of themselves. )
 ==Deployment==
-This BIP will be deployed via UASF-style block height activation. Block height TBD. 
+This BIP deploys when/if >51% hashrate runs [https://github.com/LayerTwo-Labs/bip300301_enforcer/ the enforcer client].
 Ideally, a critical mass of users would also run the enforcer client -- this would strongly dissuade miners from ever de-activating it.
 ==Reference Implementation==
-See: https://github.com/drivechain-project/mainchain
+The enforcer is [https://github.com/LayerTwo-Labs/bip300301_enforcer/ here].
-Also, for interest, see an example sidechain here: https://github.com/drivechain-project/sidechains/tree/testchain
+Also, several example L2s are [https://releases.drivechain.info/ here].
 ==References==
 https://github.com/drivechain-project/mainchain
 https://github.com/drivechain-project/sidechains/tree/testchain
 See http://www.drivechain.info/literature/index.html
 ==Credits==
 Thanks to everyone who contributed to the discussion, especially: Luke Dashjr, ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Chris Stewart, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Ben Goldhaber.
 ==Copyright==
--- a/bip-0301.mediawiki
+++ b/bip-0301.mediawiki
@ -15,9 +15,9 @@
 ==Abstract==
-Blind Merged Mining (BMM) allows miners to mine a Sidechain/Altcoin, without running its node software (ie, without "looking" at it, hence "blind").
+Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (i.e., without "looking" at those alt-chains, hence "blind").
-Instead, a separate sidechain user runs their node and constructs the block, paying himself the transaction fees. He then uses an equivalent amount of money to "buy" the right to find this block, from the conventional layer1 Sha256d miners.
+Instead, this block-assembly work is done by alt-chain users. They choose the alt-chain block, and what txns go in it, the fees etc. Simultaneously, these users "bid" on L1 to win the right to be the sole creator of the alt-chain block. BIP-301 ensures that L1 miners only accept one bid (per 10 minutes, per L2 category), instead of taking all of them (which is what they would ordinarily do).
 ==Motivation==
@ -32,9 +32,9 @@ However, traditional MM has two drawbacks:
 ==Notation and Example==
-Note: We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
+We use notation side:\* and main:\* in front of otherwise ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain/alt-chain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
-Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.10 fee; therefore, the block is worth $2000 of fee-revenue. As usual: the sidechain's coinbase txn will pay this $2000 to someone (in this case, "Simon"). Under Bip301, Simon does no hashing, but instead makes one layer1 txn paying $1999 to the layer1 miners ("Mary").
+Furthermore, here is an example of BIP-301 in use. Imagine that a side:block contains 20,000 txns, each paying a $0.10 fee; therefore, the side:block is worth $2000 of fee revenue. In BIP-301, the sidechain's coinbase txn will pay this $2000 to "Simon". Simon does no hashing, but instead makes one L1 txn paying $1999 to the L1 miners ("Mary"). Thus, Mary ends up with all of the fee revenue, even though she didn't do anything on the sidechain.
 {| class="wikitable"
@ -71,119 +71,88 @@ Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.1
 |}
-Bip301 makes this specialization-of-labor trustless on layer1. If Mary takes Simon's money, then she must let Simon control the side:block.
+BIP-301 makes this specialization-of-labor trustless on L1. If Mary takes Simon's money, then she must let Simon control the side:block.
 ==Specification==
 Each candidate for next side:block is defined by its unique side:blockhash "h*". (Even if the entire rest of the L2 block is identical, different Simons will have different side:coinbases and therefore different h*.)
-Bip300 consists of two messages: "BMM Accept" and "BMM Request". These govern something called "h*".
+BIP-301 consists of two messages: "BMM Accept" and "BMM Request".
-So we will discuss:
+# "BMM Accept" -- A coinbase output in L1, which contains h*. Mary can only choose one h* to endorse.
 # "BMM Request" -- A transaction where Simon offers to pay Mary, if (and only if) Mary's L1 block contains Simon's h*.
-# h* -- The sidechain's hashMerkleRoot, and why it matters.
+As a miner, Mary controls the main:coinbase, so she may select any h*. Her selection determines which side:block is "found" -- and which associated BMM Request she can collect.
 # "BMM Accept" -- How h* enters a main:coinbase. When Mary "accepts" a BMM Request, Mary is ''endorsing a side:block''.
 # "BMM Request" -- Simon offering money to Mary, if (and only if) she will Endorse a specific h*. When Simon broadcasts a BMM Request, Simon is ''attempting a side:block''.
 === h* ===
 h* ("h star") is the sidechain's Merkle Root hash. 
 In Bip301, a sidechain's coinbase txn acts as a header (it contains the hash of the previous side:block, and previous main:block). Thus, the MerkleRoot contains everything important.
 Note: in Bip301 sidechains, "headers" and "block hashes" do not have significant consensus meaning and are in the design mainly to help with IBD. (In the mainchain, in contrast, headers and block hashes determine the difficulty adjustments and cumulative PoW.)
 <img src="bip-0301/sidechain-headers.png?raw=true" align="middle"></img>
 Above: h* is located in the main:coinbase. h* contains all side:txns, including the side:coinbase. The side:coinbase contains many "header-like" fields, such as the hash of the previous side:block.
 Mary controls the main:coinbase, so she may select any h*. Her selection will determine which side:block is "found".
 === BMM Accept  ===
-To "Accept" the BMM proposal (and to accept Simon's money), Mary must endorse Simon's block.
+To "Accept" a BMM proposal (endorsing Simon's side:block, and allowing Mary to accept Simon's money later in the block), Mary places an OP_RETURN output into the main:coinbase as follows:
 <pre>
 For each side:block Mary wishes to endorse, Mary places the following into a main:coinbase OP_RETURN:
    1-byte - OP_RETURN (0x6a)
    4-bytes - Message header (0xD1617368)
    1-byte - Sidechain number (0-255)
    32-bytes - h* (obtained from Simon)
 </pre>
-[https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L3530-L3572 Code details here].
+[https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L252-L264 Code details here].
 If these OP_RETURN outputs are not present, then no Requests were accepted. (And, Mary would get no money from Requests.)
-It is possible for Mary and Simon to be the same person.They would trust each other completely, so the BMM process would stop here. There would only be Accepts; Requests would be unnecessary.
+It is possible for Mary and Simon to be the same person. They would trust each other completely, so the BMM process would stop here. There would only be Accepts; Requests would be unnecessary.
 When Simon and Mary are different people, Simon will need to use BMM Requests.
 === BMM Request ===
-Simon will use BMM Requests to buy the right to find a sidechain block, from Mary.
+Simon will use BMM Requests to buy the "right" to find a sidechain block, from Mary.
 For each side:block that Simon wants to attempt, he broadcasts a txn containing the following as an OP_RETURN:
 <pre>
-For each side:block that Simon wants to attempt, he broadcasts a txn containing the following:
+    1-byte - OP_RETURN (0x6a)
-        3-bytes - Message header (0x00bf00)
+    3-bytes - Message header (0x00bf00)
-        32-bytes  - h* (side:MerkleRoot)
+    1-byte - Sidechain number (0-255)
-        1-byte  - nSidechain (sidechain ID number)
+    32-bytes  - h* (obtained from L2 node)
-        4-bytes - prevMainHeaderBytes (the last four bytes of the previous main:block)
+    32-bytes  - prevMainBlock (the blockhash of the previous main:block)
 </pre>
-We make use of the [https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/primitives/transaction.h#L224-L331 extended serialization format]. (SegWit used ESF to position scriptWitness data within txns; we use it here to position the five fields above.)
+h* is chosen by Simon to correspond to the side:block he wants to mine on the alt-chain. nSidechain is the number assigned to the sidechain/alt-chain when it was created.
 The Message header identifies this txn as a BMM transaction. h* is chosen by Simon to correspond to his side:block. nSidechain is the number assigned to the sidechain when it was created. preSideBlockRef allows Simon to build on any preexisting side:block (allowing him to bypass one or more invalid blocks, details below). prevMainHeaderBytes are the last four bytes of the previous main:block (details below).
 This txn is invalid if it fails any of the following checks:
 # Each "BMM Request", must match one corresponding "BMM Accept" (previous section).
-# Only one BMM Request is allowed in each main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner singles out one BMM Request to include.
+# Only one BMM Request is allowed in each main:block, per nSidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must single out one BMM_Request_4 to include in this L1 block.
-# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about).
+# The 32-bytes of prevMainBlock must match the previous main:blockhash. Thus, Simon's txns are only valid for the current block, in the block history that he knows about.
-Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can become a bona fide transaction, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one which pays her the most.
+Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can enter the L1 block, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one that pays her the most.
 This BIP allows BMM Requests to take place over Lightning. One method is [https://www.drivechain.info/media/bmm-note/bmm-lightning/ here]. (BMM Accepts cannot be over LN, since they reside in main:coinbase txns.)
 ==Backward compatibility==
-As a soft fork, older software will continue to operate without modification. To enforce BMM trustlessly, nodes must watch "pairs" of transactions, and subject them to extra rules. Non-upgraded nodes will notice that this activity is present in the blockchain, but they will not understand any of it.
+This soft fork can be deployed without modifying Bitcoin Core at all (ie, via [https://bip300cusf.com/ CUSF]).
 Much like P2SH or a new OP Code, these old users can never be directly affected by the fork, as they will have no expectations of receiving payments of this kind. (As a matter of fact, the only people receiving BTC here, all happen to be miners. So there is less reason than ever to expect compatibility problems.)
 As with all previous soft forks, non-upgraded users are indirectly affected, in that they are no longer performing full validation.
 ==Deployment==
-This BIP will be deployed via UASF-style block height activation. Block height TBD.
+This BIP deploys when/if >51% hashrate runs [https://github.com/LayerTwo-Labs/bip300301_enforcer/ the enforcer client].
 Ideally, a critical mass of users would also run the enforcer client -- this would strongly dissuade miners from ever de-activating it.
 ==Reference Implementation==
-See: https://github.com/drivechain-project/mainchain
+The enforcer is [https://github.com/LayerTwo-Labs/bip300301_enforcer/ here].
-Also, for interest, see an example sidechain here: https://github.com/drivechain-project/sidechains/tree/testchain
+Also, several example L2s using BIP-301 are [https://releases.drivechain.info/ here].
 ==References==
 * http://www.drivechain.info/literature/index.html
 * http://www.truthcoin.info/blog/blind-merged-mining/
 * http://www.truthcoin.info/images/bmm-outline.txt
 ==Thanks==
 Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Chris Stewart, Ben Goldhaber.
 ==Copyright==
 This BIP is licensed under the BSD 2-clause license.
--- a/bip-0301/images.txt
+++ b/bip-0301/images.txt
@ -1 +0,0 @@
 Images used as reference in the documentation.
--- a/bip-0301/m1-gui.jpg
+++ b/bip-0301/m1-gui.jpg
--- a/bip-0301/sidechain-headers.png
+++ b/bip-0301/sidechain-headers.png
--- a/bip-0301/witness-vs-critical.png
+++ b/bip-0301/witness-vs-critical.png
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@ -174,8 +174,8 @@ Given below parameters:
 Produce signatures:
-* Message = "" (empty string): <code>AkcwRAIgM2gBAQqvZX15ZiysmKmQpDrG83avLIT492QBzLnQIxYCIBaTpOaD20qRlEylyxFSeEA2ba9YOixpX8z46TSDtS40ASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=</code>
+* Message = "" (empty string): <code>AkcwRAIgM2gBAQqvZX15ZiysmKmQpDrG83avLIT492QBzLnQIxYCIBaTpOaD20qRlEylyxFSeEA2ba9YOixpX8z46TSDtS40ASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=</code> or <code>AkgwRQIhAPkJ1Q4oYS0htvyuSFHLxRQpFAY56b70UvE7Dxazen0ZAiAtZfFz1S6T6I23MWI2lK/pcNTWncuyL8UL+oMdydVgzAEhAsfxIAMZZEKUPYWI4BruhAQjzFT8FSFSajuFwrDL1Yhy</code>
-* Message = "Hello World": <code>AkcwRAIgZRfIY3p7/DoVTty6YZbWS71bc5Vct9p9Fia83eRmw2QCICK/ENGfwLtptFluMGs2KsqoNSk89pO7F29zJLUx9a/sASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=</code>
+* Message = "Hello World": <code>AkcwRAIgZRfIY3p7/DoVTty6YZbWS71bc5Vct9p9Fia83eRmw2QCICK/ENGfwLtptFluMGs2KsqoNSk89pO7F29zJLUx9a/sASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=</code> or <code>AkgwRQIhAOzyynlqt93lOKJr+wmmxIens//zPzl9tqIOua93wO6MAiBi5n5EyAcPScOjf1lAqIUIQtr3zKNeavYabHyR8eGhowEhAsfxIAMZZEKUPYWI4BruhAQjzFT8FSFSajuFwrDL1Yhy</code>
 === Transaction Hashes ===
--- a/bip-0324.mediawiki
+++ b/bip-0324.mediawiki
@ -7,7 +7,7 @@
          Jonas Schnelli <dev@jonasschnelli.ch>
          Pieter Wuille <bitcoin-dev@wuille.net>
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0324
-  Status: Draft
+  Status: Final
  Type: Standards Track
  Created: 2019-03-08
  License: BSD-3-Clause
@ -384,7 +384,7 @@ def complete_handshake(peer, initiating, decoy_content_lengths=[]):
        if received_garbage[-16:] == peer.recv_garbage_terminator:
            # Receive, decode, and ignore version packet.
            # This includes skipping decoys and authenticating the received garbage.
-            v2_receive_packet(peer, aad=received_garbage)
+            v2_receive_packet(peer, aad=received_garbage[:-16])
            return
        else:
            received_garbage += recv(peer, 1)
--- a/bip-0324/xswiftec_test_vectors.csv
+++ b/bip-0324/xswiftec_test_vectors.csv
@ -1,33 +0,0 @@
 u,x,case0_t,case1_t,case2_t,case3_t,case4_t,case5_t,case6_t,case7_t
 08da7c45cb204377e7e42249cda5713fa865116ddbb4cb5a1949b2e5b438a6ab,e087b707dabf2796b03b2fb4f976c3f2f5abb36110d00ef656432117f2c93f0a,,,,,,,,
 0a6361b3a802f55cd5ae06101c88a1e216320fe11cc0cfe1d791eed08a1200fd,a0223bc98997647daf4d520129bdb66e4937a00d1533af1fa29645fb96fb5bb5,60a3ed14bd9df0bfb89ada9372a7b5790b123a66bf130f5788237e8cd5225de4,9c4ee4629f10220fda49532d0c859a539dec5148eefc78bf48d93d2828027a9c,fc5e72f042fd1792cbf88728a374a2cc1e03e1f9ec8813fa3692e497cfa7d5e6,cb39fac005f26dc0a383ea64cb9b3b0b26767f20232cae4486f32904df4f04e3,9f5c12eb42620f404765256c8d584a86f4edc59940ecf0a877dc81722add9e4b,63b11b9d60efddf025b6acd2f37a65ac6213aeb711038740b726c2d6d7fd8193,03a18d0fbd02e86d340778d75c8b5d33e1fc1e061377ec05c96d1b6730582649,34c6053ffa0d923f5c7c159b3464c4f4d98980dfdcd351bb790cd6fa20b0f74c
 102b51b9765a56a3e899f7cf0ee38e5251f9c503b357b330a49183eb7b155604,102b51b9765a56a3e899f7cf0ee38e5251f9c503b357b330a49183eb7b155604,bdb5bd58ca96eae36147a6c55bc2bef2cee55a757ee193cb619edc8d3590f90a,bda953c1da02059350e740b83f59149628e0be50c24ac8dc6908a2225931b4a0,,,424a42a73569151c9eb8593aa43d410d311aa58a811e6c349e612371ca6f0325,4256ac3e25fdfa6caf18bf47c0a6eb69d71f41af3db5372396f75ddca6ce478f,,
 2921a11f25dadaa24aa79a548e4e81508c2e5e56af2d833d65e2bcce448ce2f5,3a70c472406b83d9f1c4398b8ecef786499bc44a3b30c34ac30f2d8a418bffa3,b9c76c21d3fabb948fa0326bf9e999068e9eed56ee4e76cb81558aa26969c56c,ef7dd84338732a0cac3a8995f3bacf9b2896582b8d3317ed508e5d9a5a3447af,,,463893de2c05446b705fcd94061666f9716112a911b189347eaa755c969636c3,108227bcc78cd5f353c5766a0c453064d769a7d472cce812af71a264a5cbb480,,
 33b67cb5385ceddad93d0ee960679041613bed34b8b4a5e6362fe7539ba2d3ce,0105c74958a165e016502eeb87835195505d89714c95272b6fa88fe6c60b33ac,,,069e1b3b155c6da989b9b6a8735bba3c5c1049dcf01fe4474772244db89cf9ca,c77b10bca540e95ee66c1f57ab6297787849a89b2b883116e700593e3c0fe66d,,,f961e4c4eaa39256764649578ca445c3a3efb6230fe01bb8b88ddbb147630265,3884ef435abf16a11993e0a8549d688787b65764d477cee918ffa6c0c3f015c2
 3a898eecdae167231275338e9a79153cbe53f7bf99943eeb72ee64e57bb58699,41ffd7362aaa7b90fe03936deeebe9afafd9c18967122d8f972db2c050d4f07b,60abf7ed2a7ffd3d2ac242a782331ea663d55ca157af994e5e964e9c79a0db40,3c3c39dc37753ab9160dfbc2e0596c3a5114784690caa1836e12036814453da3,adcd3f100de60723f127278998c591fbf081af8e0a77f2a9090bed67d8aa2aa3,,9f540812d58002c2d53dbd587dcce1599c2aa35ea85066b1a169b162865f20ef,c3c3c623c88ac546e9f2043d1fa693c5aeeb87b96f355e7c91edfc96ebbabe8c,5232c0eff219f8dc0ed8d876673a6e040f7e5071f5880d56f6f412972755d18c,
 46e04d129d7b45d054469ce34e24069a1426b3e34f1b68a3d1bff1e070aee192,c6ce9611bd908c16eba5c599e5219de2d18d82c96aafb0180b23ee315513618f,,,,,,,,
 47dc540c94ceb704a23875c11273e16bb0b8a87aed84de911f2133568115f254,13964717dbc998964d7c19ec3d9981fe1d4a9a80845552a98fb9352898532844,,,,,,,,
 4cab73ce2a7e6220975001c8a354143267a3c1ce8bf7692313e654481e616a93,9114cf2edd3b53dbb6581290a5cca532db38b4e9ceeacc9b0437a0e49bf97211,903b600ed648d4ddc48f0f628829c8992c88fab44b692413fb8b3d783854f9a2,2952afe39557606d08c311345788a5071413580917207c86ea7cb829cf2f2c6d,05f414320d0c4004cff10f798c3fda6c4fc335b5a2db940993b3d78147a25c18,48e2531c7e3ec99f807210d6c5330114b4f04d7345535ca5a6e6abf478bdb723,6fc49ff129b72b223b70f09d77d63766d377054bb496dbec0474c286c7ab028d,d6ad501c6aa89f92f73ceecba8775af8ebeca7f6e8df8379158347d530d0cfc2,fa0bebcdf2f3bffb300ef08673c02593b03cca4a5d246bf66c4c287db85da017,b71dace381c136607f8def293accfeeb4b0fb28cbaaca35a5919540a8742450c
 5aeca385d8b781825b07bbec7c858b7170426c88088935850bc13dd6402368a5,a5135c7a27487e7da4f84413837a748e8fbd9377f776ca7af43ec228bfdc938a,8da4f71fb2700758f623d73c24ac91747da43f2302fce16c8d438a769c63495f,6b8f345fc0a25a76455541ddbf2791ff4b943c98b16db2b6eb6cea94a6b19afb,,,725b08e04d8ff8a709dc28c3db536e8b825bc0dcfd031e9372bc7588639cb2d0,9470cba03f5da589baaabe2240d86e00b46bc3674e924d491493156a594e6134,,
 707bf0b938f307b5c222e670598b865d5e1f8a8003df82c7abbf7c9f8fa4d720,8f840f46c70cf84a3ddd198fa67479a2a1e0757ffc207d385440835f705b250f,,,eab90fb459bace62d3ce8fbd69c9f1039f0627d0e93e2f42bffd87889cb236a4,157c26578b226c66daf8edfa56f7560f1131f41d1685175e6d76cc95b4f89f10,,,1546f04ba645319d2c31704296360efc60f9d82f16c1d0bd40027876634dc58b,ea83d9a874dd939925071205a908a9f0eece0be2e97ae8a1928933694b075d1f
 766caa663e1025b9accd7ededd24fbc8193180e028eedae2f41d6bb0b1d36468,22825ee826f8b76c27220e43c79c884a8518bc20f4978cc15f83f9c48346a314,,,8fe95c178da66d1dd249ea6a4dc614a6d46d79c83cbc4beafee518090263e48a,7b044cb756eb207226db302ba05e164781c2f5161dccd72607282cb9ad86a282,,,7016a3e8725992e22db61595b239eb592b928637c343b415011ae7f5fd9c17a5,84fbb348a914df8dd924cfd45fa1e9b87e3d0ae9e23328d9f8d7d345527959ad
 78a23af8da46b1b37e8767921a2d3f528fdc8eca37cea8aea775fd2b283d3776,73d5f35d96f3ce1ef5802ead8edc10787700c593b5e0ddcc3bfb2720b9d36de3,8465ad20bd0f2b4a2d37106769af46288a109bc10b527c3b033c930c0e4b1025,1b7f03bd2c915bb736622aec85601bcabec89268c98945e19a0de4126ed62524,,,7b9a52df42f0d4b5d2c8ef989650b9d775ef643ef4ad83c4fcc36cf2f1b4ec0a,e480fc42d36ea448c99dd5137a9fe43541376d973676ba1e65f21bec9129d70b,,
 78b4be1f9eeef9da65c393e4385f67edd142709b400ca7d900bd952e0c3cf727,089329e17a58a91e71ffe6ddd851e8a352e85a29fcc289b34a3bfdeaf958fe91,,,6008d703955b38da0166bd975ad3535af3b701b2efdf653fc5e7e6eb6afff0a3,,,,9ff728fc6aa4c725fe994268a52caca50c48fe4d10209ac03a18191395000b8c,
 7a2a7c0a81d1bd595dff09b918f8ecb5b5e8493654a4f83496956ed8eb017674,85d583f57e2e42a6a200f646e707134a4a17b6c9ab5b07cb696a912614fe85bb,,,,,,,,
 913da1f8df6f8fd47593840d533ba0458cc9873996bf310460abb495b34c232a,a7803f8e02b70718443a06db502c67925640e936b3fa46dd2ed6b8f7c80fa329,67d916ba2cc154464d87ff4e0cfe3bb816b22a961831c2daf62597a8b0681e87,a4b84520f8853e5482ee7689732ed7dd7da59945d26edeee0bf5f55d3507192f,,,9826e945d33eabb9b27800b1f301c447e94dd569e7ce3d2509da68564f97dda8,5b47badf077ac1ab7d1189768cd12822825a66ba2d912111f40a0aa1caf8e300,,
 96a296d224f285c67bee93c30f8a309157f0daa35dc5b87e410b78630a09cfc7,7684ab3b1a43e20a97a7b5520e5b5347841a7d95984fd76b2478a2b710f1a2ce,,,,,,,,
 99be5efb88ca2013bd8e4eb035fd42d5245468fe9afa70d8ba9c1c419a48c4e8,08ee83ae5c7af0c9b2341e595fe347537272d94f2fe9f10b9a8f913279fc6230,,,,,,,,
 9b4fb24edd6d1d8830e272398263cdbf026b97392cc35387b991dc0248a628f9,80e81d40a50b53712a8dac5f468b0903c05219544a56af70aa152ebf17887701,,,6e94af5a32ac100c5230f1e119c538742b7051934b02f3850522cff26bd32d97,e9bd309fbf041342311be3d5bab0b9d16c9f80c6640eb47e311d3178c2adc75d,,,916b50a5cd53eff3adcf0e1ee63ac78bd48fae6cb4fd0c7afadd300c942cce98,1642cf6040fbecbdcee41c2a454f462e93607f399bf14b81cee2ce863d5234d2
 9def996cb1ea87e596b6cadccca3839a352e99d9ce07e635cdb239f38ca294f8,294850a665ab014a0e75eb4b52ee66dd8a8d2b5e453074e58afacb5e019ee90a,b1a29367b95e1996f7e393fb389e7ace812d4135f6ddcdcd77467fc000dfca8c,a340aabc95b4000e3043ba6139178c450046c985fbf09676c440bc6430ddaa5b,4c4cd400d0be335dd651370c5565c2b742a298016212a8605187b3c0751a811e,d90fa208bbb5f3f6e16c5a42b419188ec1951c1eb358f04741b7b48df9e55f79,4e5d6c9846a1e669081c6c04c76185317ed2beca0922323288b9803eff2031a3,5cbf55436a4bfff1cfbc459ec6e873baffb9367a040f69893bbf439acf2251d4,b3b32bff2f41cca229aec8f3aa9a3d48bd5d67fe9ded579fae784c3e8ae57b11,26f05df7444a0c091e93a5bd4be6e7713e6ae3e14ca70fb8be484b71061a9cb6
 a2c4aed1cf757cd9a509734a267ffc7b1166b55f4c8f9c3e3550c56e743328fc,a2c4aed1cf757cd9a509734a267ffc7b1166b55f4c8f9c3e3550c56e743328fc,,,,,,,,
 a8e437abf9c0e74dc6d51eabf2d261a00e785c7e21efeac1f322b610273ba066,5a64cce4be767964e7dba23e78e30149326c539353b647e0d5d7cc361943b13b,,,6f73bdd6b748790b5f788935ca02aee3b9e560c4ba6caf47d716fbde1dd6e92c,b1ff705694188e672f58c6a05eeecc379dd1b60fd3cb9f19fcb02b1d9cab4bc5,,,908c422948b786f4a08776ca35fd511c461a9f3b459350b828e90420e2291303,4e008fa96be77198d0a7395fa11133c8622e49f02c3460e6034fd4e16354b06a
 bf60e4349cace6bce0d552e8d783428db66d0d649bd9e430a3627e2ee14ac839,409f1bcb635319431f2aad17287cbd724992f29b64261bcf5c9d81d01eb533f6,,,,,,,,
 c0ba8a33ac67f44abff5984dfbb6f56c46b880ac2b86e1f23e7fa9c402c53ae7,4767c4cab0d08133980a8e66c3f93a055c8ae62f89a92f8dcfa47607cee0bc57,4c21052f5ffccadb4f707aa1cba828ef384d7861af1690c59d638dfee9f368e7,dbcc8fe22896478161452d44688a6b138050a4d0964470c175a521dcecc5519a,,,b3defad0a0033524b08f855e3457d710c7b2879e50e96f3a629c7200160c9348,2433701dd769b87e9ebad2bb977594ec7faf5b2f69bb8f3e8a5ade22133aaa95,,
 cbe2268747c9c8072c7f9926f2288f270637dc55bb9d14d3368361d5e47d25be,0e4e25736b614910c4984843e606b1e229def08bfd672ab61e2707cde8248c6d,,,c30567184201fac8e1cb9e776d921e17d28cdb7333223abd1c8f860a16393df1,,,,3cfa98e7bdfe05371e346188926de1e82d73248cccddc542e37079f4e9c6be3e,
 ceb827ad3d3884fd4d50ae6099d6d50c09a21e72ebd309708e8b69d93df19e55,a6a0c8c94462f16f1b92502c3d5f9d1618f12ffa756227d5b19b01b9373cd940,,,,,,,,
 d57e9d4f5842134f140032eaf38b5333638e8c4b145fcf86a23d48d3e9acc0f8,2a8162b0a7bdecb0ebffcd150c74accc9c7173b4eba030795dc2b72b16533b37,349a9a592d2c56e5378ae869d646043fc09ffb8fe5fd9debd83a11274da08892,9875f58028cc991cafab9fb1183b350bc1d8d5ce5723813cc2b8434ed1a2100f,,,cb6565a6d2d3a91ac875179629b9fbc03f6004701a02621427c5eed7b25f739d,678a0a7fd73366e35054604ee7c4caf43e272a31a8dc7ec33d47bcb02e5dec20,,
 d94e7f1e9bb1f8a9b90996ba12c461b84956f0e7f230145cc594c2f80b067aa0,b4f4632803cff65c013a566748cd3386d58cd3a28f5b4721056cbe9d278a67a4,,,fad51eda7d418ee2785df9f3788ac9152576312177fc0fd83c65036750581620,749259382784be63f86cc927a5defa6aa8cecb98e38d68f6b7a7e958303c94ad,,,052ae12582be711d87a2060c877536eada89cede8803f027c39afc97afa7e60f,8b6da6c7d87b419c079336d85a210595573134671c729709485816a6cfc36782
 e545d395bb3fd971f91bf9a2b6722831df704efae6c1aa9da0989ed0970b77bb,760486143a1d512da5219d3e5febc7c5c9990d21ca7a501ed23f86c91ddee4cf,,,090892960a84c69967fe5a5d014d3ca19173e4cb72a908586fbce9d1e531a265,42a47f65d00ff2004faa98865ee8ed4f8a9a5ddc9f75042d728de335664bb546,,,f6f76d69f57b39669801a5a2feb2c35e6e8c1b348d56f7a79043162d1ace59ca,bd5b809a2ff00dffb0556779a11712b07565a223608afbd28d721cc999b446e9
 e9f86cefcfd61558fe75da7d4ea48a6c82d93191c6d49579aab49f99e543dcad,5db7371325a7bb83b030691b2d87cd9f199f43d91e302568391ac48181b7cea6,,,,,,,,
 eec4121f2a07b61aba16414812aa9afc39ab0a136360a5ace2240dc19b0464eb,0b623c5296c13218a1eb24e79d00b04bf15788f6c2f7ec100a4a16f1473124a2,,,,,,,,
 f566cc6fccc657365c0197accf3a7d6f80f85209ff666ff774f4dcbc524aa842,0a9933903339a8c9a3fe685330c582907f07adf6009990088b0b2342adb553ed,3ab8dc4ecbc0441c685436ac0d76f16393769c353be6092bd6ec4ce094106bd8,3bd189b4ef3d1baa5610f2b14cb4a2b377eb171511e6f36ef6a05a2c7c52e368,1594764c6296402aadd123675d81f3505d35f2a52c52881568eadb7b675b53f0,c64fbf71138e66de8ce0abdf3b6f51d151ca8e1037ab5b979e62b2faa15be81c,c54723b1343fbbe397abc953f2890e9c6c8963cac419f6d42913b31e6bef9057,c42e764b10c2e455a9ef0d4eb34b5d4c8814e8eaee190c91095fa5d283ad18c7,ea6b89b39d69bfd5522edc98a27e0cafa2ca0d5ad3ad77ea9715248398a4a83f,39b0408eec719921731f5420c490ae2eae3571efc854a468619d4d045ea41413
--- a/bip-0327.mediawiki
+++ b/bip-0327.mediawiki
@ -4,7 +4,7 @@
  Author: Jonas Nick <jonasd.nick@gmail.com>
          Tim Ruffing <crypto@timruffing.de>
          Elliott Jin <elliott.jin@gmail.com>
-  Status: Draft
+  Status: Active
  License: BSD-3-Clause
  Type: Informational
  Created: 2022-03-22
@ -190,9 +190,6 @@ The aggregate public key can be ''tweaked'', which modifies the key as defined i
 In order to apply a tweak, the KeyAgg Context output by ''KeyAgg'' is provided to the ''ApplyTweak'' algorithm with the ''is_xonly_t'' argument set to false for plain tweaking and true for X-only tweaking.
 The resulting KeyAgg Context can be used to apply another tweak with ''ApplyTweak'' or obtain the aggregate public key with ''GetXonlyPubkey'' or ''GetPlainPubkey''.
 In addition to individual public keys, the ''KeyAgg'' algorithm accepts tweaks, which modify the aggregate public key as defined in the [[#tweaking-definition|Tweaking Definition]] subsection.
 For example, if ''KeyAgg'' is run with ''v = 2'', ''is_xonly_t<sub>1</sub> = false'', ''is_xonly_t<sub>2</sub> = true'', then the aggregate key is first plain tweaked with ''tweak<sub>1</sub>'' and then X-only tweaked with ''tweak<sub>2</sub>''.
 The purpose of supporting tweaking is to ensure compatibility with existing uses of tweaking, i.e., that the result of signing is a valid signature for the tweaked public key.
 The MuSig2 algorithms take arbitrary tweaks as input but accepting arbitrary tweaks may negatively affect the security of the scheme.<ref>It is an open question whether allowing arbitrary tweaks from an adversary affects the unforgeability of MuSig2.</ref>
 Instead, signers should obtain the tweaks according to other specifications.
@ -554,7 +551,7 @@ influence whether ''sk<sub>1</sub>'' or ''sk<sub>2</sub>'' is provided to ''Sign
 This degree of freedom may allow the adversary to perform a generalized birthday attack and thereby forge a signature
 (see [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021000.html bitcoin-dev mailing list post] and [https://github.com/jonasnick/musig2-tweaking writeup] for details).
-Checking ''pk'' against ''InvidualPubkey(sk)'' is a simple way to ensure
+Checking ''pk'' against ''IndividualPubkey(sk)'' is a simple way to ensure
 that the secret key provided to ''Sign'' is fully determined already when ''NonceGen'' is invoked.
 This removes the adversary's ability to influence the secret key after having seen the ''pubnonce''
 and thus rules out the attack.<ref>Ensuring that the secret key provided to ''Sign'' is fully determined already when ''NonceGen'' is invoked is a simple policy to rule out the attack,
@ -622,7 +619,7 @@ Algorithm ''DeterministicSign(sk, aggothernonce, pk<sub>1..u</sub>, tweak<sub>1.
 * Let ''keyagg_ctx<sub>0</sub> = KeyAgg(pk<sub>1..u</sub>)''; fail if that fails
 * For ''i = 1 .. v'':
 ** Let ''keyagg_ctx<sub>i</sub> = ApplyTweak(keyagg_ctx<sub>i-1</sub>, tweak<sub>i</sub>, is_xonly_t<sub>i</sub>)''; fail if that fails
-* Let ''aggpk = GetPubkey(keyagg_ctx<sub>v</sub>)''
+* Let ''aggpk = GetXonlyPubkey(keyagg_ctx<sub>v</sub>)''
 * Let ''k<sub>i</sub> = int(hash<sub>MuSig/deterministic/nonce</sub>(sk' || aggothernonce || aggpk || bytes(8, len(m)) || m || bytes(1, i - 1))) mod n'' for ''i = 1,2''
 * Fail if ''k<sub>1</sub> = 0'' or ''k<sub>2</sub> = 0''
 * Let ''R<sub>⁎,1</sub> = k<sub>1</sub>⋅G, R<sub>⁎,2</sub> = k<sub>2</sub>⋅G''
@ -785,6 +782,10 @@ An exception to this rule is <code>MAJOR</code> version zero (0.y.z) which is fo
 The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added.
 The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.).
 * '''1.0.2''' (2024-07-22):
 ** Fix minor bug in the specification of ''DeterministicSign'' and add small improvement to a ''PartialSigAgg'' test vector.
 * '''1.0.1''' (2024-05-14):
 ** Fix minor issue in ''PartialSigVerify'' vectors.
 * '''1.0.0''' (2023-03-26):
 ** Number 327 was assigned to this BIP.
 * '''1.0.0-rc.4''' (2023-03-02):
@ -826,4 +827,4 @@ The <code>PATCH</code> version is incremented for other changes that are notewor
 == Acknowledgements ==
-We thank Brandon Black, Riccardo Casatta, Lloyd Fournier, Russell O'Connor, and Pieter Wuille for their contributions to this document.
+We thank Brandon Black, Riccardo Casatta, Sivaram Dhakshinamoorthy, Lloyd Fournier, Russell O'Connor, and Pieter Wuille for their contributions to this document.
--- a/bip-0327/gen_vectors_helper.py
+++ b/bip-0327/gen_vectors_helper.py
@ -153,7 +153,8 @@ def sig_agg_vectors():
        "psig_indices": [7, 8],
        "error": {
            "type": "invalid_contribution",
-            "signer": 1
+            "signer": 1,
            "contrib": "psig",
        },
        "comment": "Partial signature is invalid because it exceeds group size"
    }
--- a/bip-0327/reference.py
+++ b/bip-0327/reference.py
@ -317,7 +317,7 @@ SessionContext = NamedTuple('SessionContext', [('aggnonce', bytes),
                                               ('is_xonly', List[bool]),
                                               ('msg', bytes)])
-def key_agg_and_tweak(pubkeys: List[PlainPk], tweaks: List[bytes], is_xonly: List[bool]):
+def key_agg_and_tweak(pubkeys: List[PlainPk], tweaks: List[bytes], is_xonly: List[bool]) -> KeyAggContext:
    if len(tweaks) != len(is_xonly):
        raise ValueError('The `tweaks` and `is_xonly` arrays must have the same length.')
    keyagg_ctx = key_agg(pubkeys)
@ -440,8 +440,6 @@ def partial_sig_verify_internal(psig: bytes, pubnonce: bytes, pk: bytes, session
    Re_s_ = point_add(R_s1, point_mul(R_s2, b))
    Re_s = Re_s_ if has_even_y(R) else point_negate(Re_s_)
    P = cpoint(pk)
    if P is None:
        return False
    a = get_session_key_agg_coeff(session_ctx, P)
    g = 1 if has_even_y(Q) else n - 1
    g_ = g * gacc % n
@ -523,7 +521,7 @@ def test_key_agg_vectors() -> None:
        assert get_xonly_pk(key_agg(pubkeys)) == expected
-    for i, test_case in enumerate(error_test_cases):
+    for test_case in error_test_cases:
        exception, except_fn = get_error_details(test_case)
        pubkeys = [X[i] for i in test_case["key_indices"]]
@ -572,7 +570,7 @@ def test_nonce_agg_vectors() -> None:
        expected = bytes.fromhex(test_case["expected"])
        assert nonce_agg(pubnonces) == expected
-    for i, test_case in enumerate(error_test_cases):
+    for test_case in error_test_cases:
        exception, except_fn = get_error_details(test_case)
        pubnonces = [pnonce[i] for i in test_case["pnonce_indices"]]
        assert_raises(exception, lambda: nonce_agg(pubnonces), except_fn)
@ -598,7 +596,10 @@ def test_sign_verify_vectors() -> None:
    aggnonces = fromhex_all(test_data["aggnonces"])
    # The aggregate of the first three elements of pnonce is at index 0
-    assert(aggnonces[0] == nonce_agg([pnonce[0], pnonce[1], pnonce[2]]))
+    assert (aggnonces[0] == nonce_agg([pnonce[0], pnonce[1], pnonce[2]]))
    # The aggregate of the first and fourth elements of pnonce is at index 1,
    # which is the infinity point encoded as a zeroed 33-byte array
    assert (aggnonces[1] == nonce_agg([pnonce[0], pnonce[3]]))
    msgs = fromhex_all(test_data["msgs"])
@ -626,7 +627,7 @@ def test_sign_verify_vectors() -> None:
        assert sign(secnonce_tmp, sk, session_ctx) == expected
        assert partial_sig_verify(expected, pubnonces, pubkeys, [], [], msg, signer_index)
-    for i, test_case in enumerate(sign_error_test_cases):
+    for test_case in sign_error_test_cases:
        exception, except_fn = get_error_details(test_case)
        pubkeys = [X[i] for i in test_case["key_indices"]]
@ -646,7 +647,7 @@ def test_sign_verify_vectors() -> None:
        assert not partial_sig_verify(sig, pubnonces, pubkeys, [], [], msg, signer_index)
-    for i, test_case in enumerate(verify_error_test_cases):
+    for test_case in verify_error_test_cases:
        exception, except_fn = get_error_details(test_case)
        sig = bytes.fromhex(test_case["sig"])
@ -702,7 +703,7 @@ def test_tweak_vectors() -> None:
        assert sign(secnonce_tmp, sk, session_ctx) == expected
        assert partial_sig_verify(expected, pubnonces, pubkeys, tweaks, is_xonly, msg, signer_index)
-    for i, test_case in enumerate(error_test_cases):
+    for test_case in error_test_cases:
        exception, except_fn = get_error_details(test_case)
        pubkeys = [X[i] for i in test_case["key_indices"]]
@ -747,7 +748,7 @@ def test_det_sign_vectors() -> None:
        session_ctx = SessionContext(aggnonce, pubkeys, tweaks, is_xonly, msg)
        assert partial_sig_verify_internal(psig, pubnonce, pubkeys[signer_index], session_ctx)
-    for i, test_case in enumerate(error_test_cases):
+    for test_case in error_test_cases:
        exception, except_fn = get_error_details(test_case)
        pubkeys = [X[i] for i in test_case["key_indices"]]
@ -796,7 +797,7 @@ def test_sig_agg_vectors() -> None:
        aggpk = get_xonly_pk(key_agg_and_tweak(pubkeys, tweaks, is_xonly))
        assert schnorr_verify(msg, aggpk, sig)
-    for i, test_case in enumerate(error_test_cases):
+    for test_case in error_test_cases:
        exception, except_fn = get_error_details(test_case)
        pubnonces = [pnonce[i] for i in test_case["nonce_indices"]]
--- a/bip-0327/vectors/sig_agg_vectors.json
+++ b/bip-0327/vectors/sig_agg_vectors.json
@ -143,7 +143,8 @@
            ],
            "error": {
                "type": "invalid_contribution",
-                "signer": 1
+                "signer": 1,
                "contrib": "psig"
            },
            "comment": "Partial signature is invalid because it exceeds group size"
        }
--- a/bip-0327/vectors/sign_verify_vectors.json
+++ b/bip-0327/vectors/sign_verify_vectors.json
@ -157,7 +157,7 @@
    ],
    "verify_fail_test_cases": [
        {
-            "sig": "97AC833ADCB1AFA42EBF9E0725616F3C9A0D5B614F6FE283CEAAA37A8FFAF406",
+            "sig": "FED54434AD4CFE953FC527DC6A5E5BE8F6234907B7C187559557CE87A0541C46",
            "key_indices": [0, 1, 2],
            "nonce_indices": [0, 1, 2],
            "msg_index": 0,
@ -165,7 +165,7 @@
            "comment": "Wrong signature (which is equal to the negation of valid signature)"
        },
        {
-            "sig": "68537CC5234E505BD14061F8DA9E90C220A181855FD8BDB7F127BB12403B4D3B",
+            "sig": "012ABBCB52B3016AC03AD82395A1A415C48B93DEF78718E62A7A90052FE224FB",
            "key_indices": [0, 1, 2],
            "nonce_indices": [0, 1, 2],
            "msg_index": 0,
@ -183,7 +183,7 @@
    ],
    "verify_error_test_cases": [
        {
-            "sig": "68537CC5234E505BD14061F8DA9E90C220A181855FD8BDB7F127BB12403B4D3B",
+            "sig": "012ABBCB52B3016AC03AD82395A1A415C48B93DEF78718E62A7A90052FE224FB",
            "key_indices": [0, 1, 2],
            "nonce_indices": [4, 1, 2],
            "msg_index": 0,
@ -196,7 +196,7 @@
            "comment": "Invalid pubnonce"
        },
        {
-            "sig": "68537CC5234E505BD14061F8DA9E90C220A181855FD8BDB7F127BB12403B4D3B",
+            "sig": "012ABBCB52B3016AC03AD82395A1A415C48B93DEF78718E62A7A90052FE224FB",
            "key_indices": [3, 1, 2],
            "nonce_indices": [0, 1, 2],
            "msg_index": 0,
--- a/bip-0328.mediawiki
+++ b/bip-0328.mediawiki
@ -0,0 +1,80 @@
 <pre>
  BIP: 328
  Layer: Applications
  Title: Derivation Scheme for MuSig2 Aggregate Keys
  Author: Ava Chow <me@achow101.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0328
  Status: Draft
  Type: Informational
  Created: 2024-01-15
  License: CC0-1.0
 </pre>
 ==Abstract==
 This document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2
 aggregate public key and how such keys should be used for key derivation.
 ==Copyright==
 This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
 ==Motivation==
 Multiple signers can create a single aggregate public key with MuSig2 that is indistinguishable
 from a random public key. The cosigners need a method for generating additional aggregate pubkeys
 to follow the best practice of using a new address for every payment.
 The obvious method is for the cosigners to generate multiple public keys and produce a
 new aggregate pubkey every time one is needed. This is similar to how multisig using Bitcoin script
 works where all of the cosigners share their extended public keys and do derivation to produce
 the multisig script. The same could be done with MuSig2 and instead of producing a multisig script,
 the result would be a MuSig2 aggregate pubkey.
 However, it is much simpler to be able to derive from a single extended public key instead of having
 to derive from many extended public keys and aggregate them. As MuSig2 produces a normal looking
 public key, the aggregate public can be used in this way. This reduces the storage and computation
 requirements for generating new aggregate pubkeys.
 ==Specification==
 A synthetic xpub can be created from a BIP 327 MuSig2 plain aggregate public key by setting
 the depth to 0, the child number to 0, and attaching a chaincode with the byte string
 <tt>868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965</tt><ref>'''Where does this
 constant chaincode come from?''' It is the SHA256 of the text <tt>MuSig2MuSig2MuSig2</tt></ref>.
 This fixed chaincode should be used by all such synthetic xpubs following this specification.
 Unhardened child public keys can be derived from the synthetic xpub as with any other xpub. Since
 the aggregate public key is all that is necessary to produce the synthetic xpub, any aggregate
 public key that will be used in this way shares the same privacy concerns as typical xpubs.
 Furthermore, as there is no aggregate private key, only unhardened derivation from the aggregate
 public key is possible.
 When signing, all signers must compute the tweaks used in the BIP 32 derivation for the child key
 being signed for. The I<sub>L</sub> value computed in ''CKDpub'' is the tweak used at each
 derivation step. These are provided in the session context, each with a tweak mode of plain
 (''is_xonly_t = false''). When the ''Sign'' algorithm is used, the tweaks will be applied to the
 partial signatures.
 ==Test Vectors==
 TBD
 ==Backwards Compatibility==
 Once a synthetic xpub is created, it is fully backwards compatible with BIP 32 - only unhardened
 derivation can be done, and the signers will be able to produce a signature for any derived children.
 ==Rationale==
 <references/>
 ==Reference Implementation==
 TBD
 ==Acknowledgements==
 Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who
 participated in discussions on this topic.
--- a/bip-0329.mediawiki
+++ b/bip-0329.mediawiki
@ -39,8 +39,8 @@ The Electrum wallet imports and exports address and transaction labels in a JSON
 ==Specification==
-In order to be lightweight, human readable and well structured, this BIP uses a JSON format. 
+In order to be lightweight, human readable and well structured, this BIP uses a JSON format.
-Further, the JSON Lines format is used (also called newline-delimited JSON)<ref>[https://jsonlines.org/ jsonlines.org]</ref>. 
+Further, the JSON Lines format is used (also called newline-delimited JSON)<ref>[https://jsonlines.org/ jsonlines.org]</ref>.
 This allows a document to be split, streamed, or incrementally added to, and limits the potential for formatting errors to invalidate an entire import.
 It is also a convenient format for command-line processing, which is often line-oriented.
@ -48,7 +48,7 @@ Further to the JSON Lines specification, an export of labels from a wallet must
 Lines are separated by <tt>\n</tt>. Multiline values are not permitted.
 Each JSON object must contain 3 or 4 key/value pairs, defined as follows:
-{| class="wikitable" 
+{| class="wikitable"
 |-
 ! Key
 ! Description
@ -71,7 +71,7 @@ Each JSON object must contain 3 or 4 key/value pairs, defined as follows:
 The reference is defined for each <tt>type</tt> as follows:
-{| class="wikitable" 
+{| class="wikitable"
 |-
 ! Type
 ! Description
@ -107,7 +107,7 @@ Each JSON object must contain both <tt>type</tt> and <tt>ref</tt> properties. Th
 If present, the optional <tt>origin</tt> property must contain an abbreviated output descriptor (as defined by BIP380<ref>[https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380]</ref>) describing a BIP32 compatible originating wallet, including all key origin information but excluding any actual keys, any child path elements, or a checksum.
 This property should be used to disambiguate transaction labels from different wallets contained in the same export, particularly when exporting multiple accounts derived from the same seed.
-Care should be taken when exporting due to the privacy sensitive nature of the data. 
+Care should be taken when exporting due to the privacy sensitive nature of the data.
 Encryption in transit over untrusted networks is highly recommended, and encryption at rest should also be considered.
 Unencrypted exports should be deleted as soon as possible.
 For security reasons no private key types are defined.
@ -120,7 +120,7 @@ For security reasons no private key types are defined.
 ==Backwards Compatibility==
-The nature of this format makes it naturally extensible to handle other record types. 
+The nature of this format makes it naturally extensible to handle other record types.
 However, importing wallets complying to this specification may ignore types not defined here.
 ==Test Vectors==
--- a/bip-0337.mediawiki
+++ b/bip-0337.mediawiki
@ -0,0 +1,301 @@
 <pre>
  BIP: 337
  Layer: API/RPC
  Title: Compressed Transactions
  Author: Tom Briar <tombriar11@protonmail.com>
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0337
  Status: Draft
  Type: Standards Track
  Created: 2024-02-01
  License: BSD-3-Clause
  Post-History: https://github.com/bitcoin/bitcoin/pull/29134
                https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html
 </pre>
 == Introduction ==
 === Abstract ===
 This document proposes a serialization scheme for compressing Bitcoin transactions. The compressed Bitcoin transactions can reach a serialized size of less than 50% of the original serialized transaction. One method for compressing involves reducing the transaction outpoints in a potentially lossy way. Therefore, it is an optional path for compression. Compressing the outpoints is necessary for compressed transactions to reach less than 70% of the original size.
 === Motivation ===
 Typical Bitcoin transactions usually contain a large amount of white space and padding due to specific fields that are often one of a minimal number of possibilities. We can use this fact and a few similar methods to create an encoding for 90% of Bitcoin transactions that are roughly 25-50% smaller.
 There exists a working-in-progress app that allows the use of steganography to encode data in images to be passed around via various social media groups. When used in conjunction with this compression scheme and an elligator squared encryption, this would allow for a very secure and private form of broadcasting bitcoin transactions.
 === Rationale ===
 The four main methods to achieve a lower transaction size are:
 1. Packing transaction metadata before it and each of its inputs and outputs to determine the following data structure.
 2. Replacing 32-bit numeric values with either variable-length integers (VarInts) or compact integers (CompactSizes).
 3. Using compressed signatures and public key recovery upon decompression.
 4. Replacing the 36-byte Outpoint txid/vout pair with a block height and index.
 === Backwards Compatibility ===
 There are no concerns with backwards compatibility.
 === Specification ===
 ==== Primitives ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | CompactSize || 1-5 Bytes || For 0-253, encode the value directly in one byte. For 254-65535, encode 254 followed by two little-endian bytes. For 65536-(2^32-1), encode 255 followed by four little-endian bytes.
 |-
 | CompactSize Flag || 2 Bits || 1, 2, or 3 indicate literal values. 0 indicates that a CompactSize encoding of the value will follow.
 |-
 | VarInt || 1+ Bytes || 7-bit little-endian encoding, with each 7-bit word encoded in a byte. The highest bit of each byte is one if more bytes follow, and 0 for the last byte.
 |-
 | VLP-Bytestream || 2+ Bytes || A VarInt Length Prefixed Bytestream. It uses the prefixed VarInt to determine the length of the following byte stream.
 |}
 ==== General Schema ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Transaction metadata || 1 Bytes || Information on the structure of the transaction. See [[#transaction-metadata|Transaction Metadata]]
 |-
 | Version || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction version.
 |-
 | Input Count || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction input count.
 |-
 | Output Count || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction output count.
 |-
 | LockTime || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction LockTime.
 |-
 | Minimum Blockheight || 1-5 Bytes || If present according to the metadata field, a VarInt encoding of the minimum block height for transaction compressed inputs and LockTime.
 |-
 | Input Metadata+Output Metadata || 1+ Bytes || An encoding containing the metadata for all the inputs followed by all the outputs of the transaction. For each input, see [[#input-metadata|Input Metadata]], and for each output, see [[#output-metadata|Output Metadata]].
 |-
 | Input Data || 66+ Bytes || See [[#input-data|Input Data]].
 |-
 | Output Data || 3+ Bytes || See [[#output-data|Output Data]].
 |}
 <span id="transaction-metadata"></span>
 ==== Transaction Metadata ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Version || 2 Bits || A CompactSize flag for the transaction version.
 |-
 | Input Count || 2 Bits || A CompactSize flag for the transaction input count.
 |-
 | Output Count || 2 Bits || A CompactSize flag for the transaction output count.
 |-
 | LockTime || 1 Bit || A boolean to indicate if the transaction has a LockTime.
 |-
 | Minimum Blockheight || 1 Bit || A boolean to indicate if the transaction minimum block height is greater than zero.
 |}
 <span id="input-metadata"></span>
 ==== Input Metadata ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Compressed Signature || 1 Bit || A Boolean do determine if this input's signature is compressed. The signature is only compressed for P2TR on a key spend and for P2SH when it is a wrapped P2SH-WPKH.
 |-
 | Standard Hash || 1 Bit || A Boolean to determine if this input's signature hash type is standard (0x00 for Taproot, 0x01 for Legacy/Segwit).
 |-
 | Standard Sequence || 2 Bits || A CompactSize flag for this input's sequence. Encode literal values as follows: 1 = 0x00000000, 2 = 0xFFFFFFFE, 3 = 0xFFFFFFFF.
 |-
 | Compressed OutPoint || 1 bit || A Boolean to determine if the input's outpoint is compressed.
 |}
 <span id="output-metadata"></span>
 ==== Output Metadata ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Encoded Script Type || 3 Bits || [[#script-type-encoding|Encoded Script Type]].
 |}
 <span id="script-type-encoding"></span>
 ==== Script Type Encoding ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Script Type !! Value
 |-
 | Uncompressed Custom Script || 0b000
 |-
 | Uncompressed P2PK || 0b001
 |-
 | Compressed P2PK || 0b010
 |-
 | P2PKH || 0b011
 |-
 | P2SH || 0b100
 |-
 | P2WPKH || 0b101
 |-
 | P2WSH || 0b110
 |-
 | P2TR || 0b111
 |}
 <span id="input-data"></span>
 ==== Input Data ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Outpoint || 2-37 Bytes || The Outpoint Txid/Vout are determined to be compressed or otherwise by the "Compressed Outpoint" Boolean in the input metadata. For each compressed outpoint see [[#compressed-outpoint|Compressed Outpoint]]. For each uncompressed signature see [[#uncompressed-outpoint|Uncompressed Outpoint]].
 |-
 | Signature || 64+ Bytes || The Signature is determined to be compressed or otherwise by the output script of the previous transaction. For each compressed signature see [[#compressed-signature|Compressed Signature]]. For each uncompressed signature see [[#uncompressed-signature|Uncompressed Signature]].
 |-
 | Sequence || 0-5 Bytes || If present due to a non-standard sequence, a VarInt encoding of the sequence.
 |}
 <span id="compressed-outpoint"></span>
 ==== Compressed Outpoint ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Txid Block Height || 1-5 Bytes || A VarInt containing the offset from Minimum Blockheight for this Txid.
 |-
 | Txid Block Index || 1-5 Bytes || A VarInt containing the flattened index from the Txid block height for the Vout.
 |}
 <span id="uncompressed-outpoint"></span>
 ==== Uncompressed Outpoint ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Txid || 32 Bytes || Contains the 32 Byte Txid.
 |-
 | Vout || 1-5 Bytes || A CompactSize Containing the Vout of the Txid.
 |}
 <span id="compressed-signature"></span>
 ==== Compressed Signature ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Signature || 64 Bytes || Contains the 64 Byte signature.
 |-
 | Pubkey Hash || 0-20 Bytes || If input is P2SH-P2WPKH contains the 20 byte hash of the public key.
 |-
 | Hash Type || 0-1 Bytes || An Optional Byte containing the Hash Type if it was non-standard.
 |}
 <span id="uncompressed-signature"></span>
 ==== Uncompressed Signature ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Signature || 2+ Bytes || A VLP-Bytestream containing the signature.
 |}
 <span id="output-data"></span>
 ==== Output Data ====
 {| class="wikitable" style="margin:auto"
 |-
 ! Name !! Width !! Description
 |-
 | Output Script || 2+ Bytes || A VLP-Bytestream containing the output script.
 |-
 | Amount || 1-9 Bytes || A VarInt containing the output amount.
 |}
 ==== Ideal Transaction ====
 The compression scheme was designed to be optimal for a "typical" transaction, spending a few close-in-age inputs and having one or two outputs. Here are size
 values for such a transaction, which demonstrate the effectiveness of the compression.
 {| class="wikitable" style="margin:auto"
 |-
 ! Field !! Requirements !! Savings Up To
 |-
 | Version || Less than four || 30 Bits
 |-
 | Input Count || Less than four || 30 Bits
 |-
 | Output Count || Less than four || 30 Bits
 |-
 | LockTime || 0 || 30 Bits
 |-
 | Input Sequence || 0x00, 0xFFFFFFFE, or 0xFFFFFFFF || 62 Bits For Each Input
 |-
 | Input Txid || Compressed Outpoint || 23 - 31 Bytes For Each Input
 |-
 | Input Vout || Compressed Outpoint || (-1) - 3 Bytes For Each Input
 |-
 | Input Signature  || Non-custom Script Signing || 40 - 72 Bytes For Each Legacy Input
 |-
 | Input Hash Type || 0x00 for Taproot, 0x01 for Legacy || 7 Bits For Each Input
 |-
 | Output Script || Non-custom Scripts || 2 - 5 Bytes For Each Output
 |-
 | Output Amount || No Restrictions || (-1) - 7 Bytes For Each Output
 |}
 === Reference Implementation ===
 This reference implementation adds two new RPC endpoints, compressrawtransaction and decompressrawtransaction. The first accepts a raw hex-encoded transaction and returns a compact hex-encoded transaction; also included in the output is a list of warnings to help ensure there are no unexpected uncompressed values. The second accepts a compact hex transaction and returns the uncompressed raw hex-encoded transaction.
 https://github.com/bitcoin/bitcoin/pull/29134
 === Test Vectors ===
 ==== Taproot ====
 ===== Uncompressed =====
 <code>020000000001017ad1d0cc314504ec06f1b5c786c50cf3cda30bd5be88cf08ead571b0ce7481fb0000000000fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226201408ce65b3170d3fbc68e3b6980650514dc53565f915d14351f83050ff50c8609495b7aa96271c3c99cdac1a92b1b45e77a4a870251fc1673596793adf2494565e500000000</code>
 ===== Compressed =====
 <code>96b1ec7f968001b0218ce65b3170d3fbc68e3b6980650514dc53565f915d14351f83050ff50c8609495b7aa96271c3c99cdac1a92b1b45e77a4a870251fc1673596793adf2494565e58efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code>
 ==== P2WPKH ====
 ===== Uncompressed =====
 <code>0200000000010144bcf05ab48b8789268a7ca07133241ad654c0739ac7165015b2d669eadb10ea0000000000fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226202473044022043ab639a98dfbc704f16a35bf25b8b72acb4cb928fd772285f1fcf63725caa85022001c9ff354504e7024708bce61f30370c8db13da8170cef4e8e4c4cdad0f71bfe0121030072484c24705512bfb1f7f866d95f808d81d343e552bc418113e1b9a1da0eb400000000</code>
 ===== Compressed =====
 <code>96b1ec71968001932643ab639a98dfbc704f16a35bf25b8b72acb4cb928fd772285f1fcf63725caa8501c9ff354504e7024708bce61f30370c8db13da8170cef4e8e4c4cdad0f71bfe8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code>
 ==== P2SH-P2WPKH ====
 ===== Uncompressed =====
 <code>0200000000010192fb2e4332b43dc9a73febba67f3b7d97ba890673cb08efde2911330f77bbdfc00000000171600147a1979232206857167b401fdac1ffbf33f8204fffdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226202473044022041eb682e63c25b85a5a400b11d41cf4b9c25f309090a5f3e0b69dc15426da90402205644ddc3d5179bab49cce4bf69ebfaeab1afa34331c1a0a70be2927d2836b0e8012103c483f1b1bd24dd23b3255a68d87ef9281f9d080fd707032ccb81c1cc56c5b00200000000</code>
 ===== Compressed =====
 <code>96b1ec7c9e8001981641eb682e63c25b85a5a400b11d41cf4b9c25f309090a5f3e0b69dc15426da9045644ddc3d5179bab49cce4bf69ebfaeab1afa34331c1a0a70be2927d2836b0e87a1979232206857167b401fdac1ffbf33f8204ff8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code>
 ==== P2PKH ====
 ===== Uncompressed =====
 <code>02000000015f5be26862482fe2fcc900f06ef26ee256fb205bc4773e5a402d0c1b88b82043000000006a473044022031a20f5d9212023b510599c9d53d082f8e07faaa2d51482e078f8e398cb50d770220635abd99220ad713a081c4f20b83cb3f491ed8bd032cb151a3521ed144164d9c0121027977f1b6357cead2df0a0a19570088a1eb9115468b2dfa01439493807d8f1294fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226200000000</code>
 ===== Compressed =====
 <code>96b1ec7c968001981431a20f5d9212023b510599c9d53d082f8e07faaa2d51482e078f8e398cb50d77635abd99220ad713a081c4f20b83cb3f491ed8bd032cb151a3521ed144164d9c8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code>
 == Acknowledgements ==
 Thank you to Andrew Poelstra, who helped invent and develop the ideas in the proposal and the code for reference implementation.
--- a/bip-0338.mediawiki
+++ b/bip-0338.mediawiki
@ -5,7 +5,7 @@
  Author: Suhas Daftuar <sdaftuar@chaincode.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0338
-  Status: Draft
+  Status: Withdrawn
  Type: Standards Track
  Created: 2020-09-03
  License: BSD-2-Clause
--- a/bip-0339.mediawiki
+++ b/bip-0339.mediawiki
@ -5,7 +5,7 @@
  Author: Suhas Daftuar <sdaftuar@chaincode.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0339
-  Status: Draft
+  Status: Final
  Type: Standards Track
  Created: 2020-02-03
  License: BSD-2-Clause
--- a/bip-0340.mediawiki
+++ b/bip-0340.mediawiki
@ -58,11 +58,11 @@ encodings and operations.
 # Signatures are pairs ''(e, s)'' that satisfy ''e = hash(s⋅G - e⋅P || m)''. This variant avoids minor complexity introduced by the encoding of the point ''R'' in the signature (see paragraphs "Encoding R and public key point P" and "Implicit Y coordinates" further below in this subsection). Moreover, revealing ''e'' instead of ''R'' allows for potentially shorter signatures: Whereas an encoding of ''R'' inherently needs about 32 bytes, the hash ''e'' can be tuned to be shorter than 32 bytes, and [http://www.neven.org/papers/schnorr.pdf a short hash of only 16 bytes suffices to provide SUF-CMA security at the target security level of 128 bits]. However, a major drawback of this optimization is that finding collisions in a short hash function is easy. This complicates the implementation of secure signing protocols in scenarios in which a group of mutually distrusting signers work together to produce a single joint signature (see Applications below). In these scenarios, which are not captured by the SUF-CMA model due its assumption of a single honest signer, a promising attack strategy for malicious co-signers is to find a collision in the hash function in order to obtain a valid signature on a message that an honest co-signer did not intend to sign.
 # Signatures are pairs ''(R, s)'' that satisfy ''s⋅G = R + hash(R || m)⋅P''. This supports batch verification, as there are no elliptic curve operations inside the hashes. Batch verification enables significant speedups.<ref>The speedup that results from batch verification can be demonstrated with the cryptography library [https://github.com/jonasnick/secp256k1/blob/schnorrsig-batch-verify/doc/speedup-batch.md libsecp256k1].</ref>
-Since we would like to avoid the fragility that comes with short hashes, the ''e'' variant does not provide significant advantages. We choose the ''R''-option, which supports batch verification. 
+Since we would like to avoid the fragility that comes with short hashes, the ''e'' variant does not provide significant advantages. We choose the ''R''-option, which supports batch verification.
 '''Key prefixing''' Using the verification rule above directly makes Schnorr signatures vulnerable to "related-key attacks" in which a third party can convert a signature ''(R, s)'' for public key ''P'' into a signature ''(R, s + a⋅hash(R || m))'' for public key ''P + a⋅G'' and the same message ''m'', for any given additive tweak ''a'' to the signing key. This would render signatures insecure when keys are generated using [[bip-0032.mediawiki#public-parent-key--public-child-key|BIP32's unhardened derivation]] and other methods that rely on additive tweaks to existing keys such as Taproot.
-To protect against these attacks, we choose ''key prefixed''<ref>A limitation of committing to the public key (rather than to a short hash of it, or not at all) is that it removes the ability for public key recovery or verifying signatures against a short public key hash. These constructions are generally incompatible with batch verification.</ref> Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to ''s⋅G = R + hash(R || P || m)⋅P''. [https://eprint.iacr.org/2015/1135.pdf It can be shown] that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving the MuSig multisignature scheme secure (see Applications below).
+To protect against these attacks, we choose ''key prefixed''<ref>A limitation of committing to the public key (rather than to a short hash of it, or not at all) is that it removes the ability for public key recovery or verifying signatures against a short public key hash. These constructions are generally incompatible with batch verification.</ref> Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to ''s⋅G = R + hash(R || P || m)⋅P''. [https://eprint.iacr.org/2015/1135.pdf It can be shown] that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving multiparty signing protocols (such as MuSig, MuSig2, and FROST) secure (see Applications below).
 We note that key prefixing is not strictly necessary for transaction signatures as used in Bitcoin currently, because signed transactions indirectly commit to the public keys already, i.e., ''m'' contains a commitment to ''pk''. However, this indirect commitment should not be relied upon because it may change with proposals such as SIGHASH_NOINPUT ([[bip-0118.mediawiki|BIP118]]), and would render the signature scheme unsuitable for other purposes than signing transactions, e.g., [https://bitcoin.org/en/developer-reference#signmessage signing ordinary messages].
@ -161,14 +161,14 @@ The auxiliary random data should be set to fresh randomness generated at signing
 ==== Alternative Signing ====
-It should be noted that various alternative signing algorithms can be used to produce equally valid signatures. The 32-byte ''rand'' value may be generated in other ways, producing a different but still valid signature (in other words, this is not a ''unique'' signature scheme). '''No matter which method is used to generate the ''rand'' value, the value must be a fresh uniformly random 32-byte string which is not even partially predictable for the attacker.''' For nonces without randomness this implies that the same inputs must not be presented in another context. This can be most reliably accomplished by not reusing the same private key across different signing schemes. For example, if the ''rand'' value was computed as per RFC6979 and the same secret key is used in deterministic ECDSA with RFC6979, the signatures can leak the secret key through nonce reuse.
+It should be noted that various alternative signing algorithms can be used to produce equally valid signatures. The 32-byte ''rand'' value may be generated in other ways, producing a different but still valid signature (in other words, this is not a ''unique'' signature scheme). '''No matter which method is used to generate the ''rand'' value, the value must be a fresh uniformly random 32-byte string which is not even partially predictable for the attacker.''' For nonces without randomness, this implies that the same inputs must not be presented in another context. This can be most reliably accomplished by not reusing the same private key across different signing schemes. For example, if the ''rand'' value was computed as per RFC6979 and the same secret key is used in deterministic ECDSA with RFC6979, the signatures can leak the secret key through nonce reuse.
-'''Nonce exfiltration protection''' It is possible to strengthen the nonce generation algorithm using a second device. In this case, the second device contributes randomness which the actual signer provably incorporates into its nonce. This prevents certain attacks where the signer device is compromised and intentionally tries to leak the secret key through its nonce selection.
+'''Nonce exfiltration protection''' It is possible to strengthen the nonce generation algorithm using a second device. In this case, the second device contributes randomness which the actual signer provably incorporates into its nonce. This prevents certain attacks where the signer's device is compromised and intentionally tries to leak the secret key through its nonce selection.
-'''Multisignatures''' This signature scheme is compatible with various types of multisignature and threshold schemes such as [https://eprint.iacr.org/2018/068 MuSig], where a single public key requires holders of multiple secret keys to participate in signing (see Applications below).
+'''Multisignatures''' This signature scheme is compatible with various types of multisignature and threshold schemes such as [https://eprint.iacr.org/2020/1261.pdf MuSig2], where a single public key requires holders of multiple secret keys to participate in signing (see Applications below).
 '''It is important to note that multisignature signing schemes in general are insecure with the ''rand'' generation from the default signing algorithm above (or any other deterministic method).'''
-'''Precomputed public key data''' For many uses the compressed 33-byte encoding of the public key corresponding to the secret key may already be known, making it easy to evaluate ''has_even_y(P)'' and ''bytes(P)''. As such, having signers supply this directly may be more efficient than recalculating the public key from the secret key. However, if this optimization is used and additionally the signature verification at the end of the signing algorithm is dropped for increased efficiency, signers must ensure the public key is correctly calculated and not taken from untrusted sources.
+'''Precomputed public key data''' For many uses, the compressed 33-byte encoding of the public key corresponding to the secret key may already be known, making it easy to evaluate ''has_even_y(P)'' and ''bytes(P)''. As such, having signers supply this directly may be more efficient than recalculating the public key from the secret key. However, if this optimization is used and additionally the signature verification at the end of the signing algorithm is dropped for increased efficiency, signers must ensure the public key is correctly calculated and not taken from untrusted sources.
 ==== Verification ====
@ -264,9 +264,9 @@ While recent academic papers claim that they are also possible with ECDSA, conse
 === Multisignatures and Threshold Signatures ===
-By means of an interactive scheme such as [https://eprint.iacr.org/2018/068 MuSig], participants can aggregate their public keys into a single public key which they can jointly sign for. This allows ''n''-of-''n'' multisignatures which, from a verifier's perspective, are no different from ordinary signatures, giving improved privacy and efficiency versus ''CHECKMULTISIG'' or other means.
+By means of an interactive scheme such as [https://eprint.iacr.org/2020/1261.pdf MuSig2] ([[bip-0327.mediawiki|BIP327]]), participants can aggregate their public keys into a single public key which they can jointly sign for. This allows ''n''-of-''n'' multisignatures which, from a verifier's perspective, are no different from ordinary signatures, giving improved privacy and efficiency versus ''CHECKMULTISIG'' or other means.
-Moreover, Schnorr signatures are compatible with [https://web.archive.org/web/20031003232851/http://www.research.ibm.com/security/dkg.ps distributed key generation], which enables interactive threshold signatures schemes, e.g., the schemes described by [http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps Stinson and Strobl (2001)] or [https://web.archive.org/web/20060911151529/http://theory.lcs.mit.edu/~stasio/Papers/gjkr03.pdf Gennaro, Jarecki and Krawczyk (2003)]. These protocols make it possible to realize ''k''-of-''n'' threshold signatures, which ensure that any subset of size ''k'' of the set of ''n'' signers can sign but no subset of size less than ''k'' can produce a valid Schnorr signature. However, the practicality of the existing schemes is limited: most schemes in the literature have been proven secure only for the case ''k-1 < n/2'', are not secure when used concurrently in multiple sessions, or require a reliable broadcast mechanism to be secure. Further research is necessary to improve this situation.
+Moreover, Schnorr signatures are compatible with [https://en.wikipedia.org/wiki/Distributed_key_generation distributed key generation], which enables interactive threshold signatures schemes, e.g., the schemes by [http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps Stinson and Strobl (2001)], by [https://link.springer.com/content/pdf/10.1007/s00145-006-0347-3.pdf Gennaro, Jarecki, Krawczyk, and Rabin (2007)], or the [https://eprint.iacr.org/2020/852.pdf FROST] scheme including its variants such as [https://eprint.iacr.org/2023/899.pdf FROST3]. These protocols make it possible to realize ''k''-of-''n'' threshold signatures, which ensure that any subset of size ''k'' of the set of ''n'' signers can sign but no subset of size less than ''k'' can produce a valid Schnorr signature.
 === Adaptor Signatures ===
@ -278,7 +278,7 @@ Adaptor signatures, beyond the efficiency and privacy benefits of encoding scrip
 === Blind Signatures ===
-A blind signature protocol is an interactive protocol that enables a signer to sign a message at the behest of another party without learning any information about the signed message or the signature. Schnorr signatures admit a very [http://publikationen.ub.uni-frankfurt.de/files/4292/schnorr.blind_sigs_attack.2001.pdf simple blind signature scheme] which is however insecure because it's vulnerable to [https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf Wagner's attack]. A known mitigation is to let the signer abort a signing session with a certain probability, and the resulting scheme can be [https://eprint.iacr.org/2019/877 proven secure under non-standard cryptographic assumptions].
+A blind signature protocol is an interactive protocol that enables a signer to sign a message at the behest of another party without learning any information about the signed message or the signature. Schnorr signatures admit a very [http://publikationen.ub.uni-frankfurt.de/files/4292/schnorr.blind_sigs_attack.2001.pdf simple blind signature scheme] which is however insecure because it's vulnerable to [https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf Wagner's attack]. Known mitigations are to let the signer abort a signing session with a certain probability, which can be [https://eprint.iacr.org/2019/877 proven secure under non-standard cryptographic assumptions], or [https://eprint.iacr.org/2022/1676.pdf to use zero-knowledge proofs].
 Blind Schnorr signatures could for example be used in [https://github.com/ElementsProject/scriptless-scripts/blob/master/md/partially-blind-swap.md Partially Blind Atomic Swaps], a construction to enable transferring of coins, mediated by an untrusted escrow agent, without connecting the transactors in the public blockchain transaction graph.
@ -293,6 +293,7 @@ To help implementors understand updates to this BIP, we keep a list of substanti
 * 2022-08: Fix function signature of lift_x in reference code
 * 2023-04: Allow messages of arbitrary size
 * 2024-05: Update "Applications" section with more recent references
 == Footnotes ==
--- a/bip-0340/test-vectors.py
+++ b/bip-0340/test-vectors.py
@ -24,17 +24,17 @@ def vector0():
    assert(y(P) % 2 == 0)
    # For historical reasons (pubkey tiebreaker was squareness and not evenness)
-    # we should have at least one test vector where the the point reconstructed
+    # we should have at least one test vector where the point reconstructed
    # from the public key has a square and one where it has a non-square Y
    # coordinate. In this one Y is non-square.
-    pubkey_point = lift_x(pubkey)
+    pubkey_point = lift_x(int_from_bytes(pubkey))
    assert(not has_square_y(pubkey_point))
    # For historical reasons (R tiebreaker was squareness and not evenness)
-    # we should have at least one test vector where the the point reconstructed
+    # we should have at least one test vector where the point reconstructed
    # from the R.x coordinate has a square and one where it has a non-square Y
    # coordinate. In this one Y is non-square.
-    R = lift_x(sig[0:32])
+    R = lift_x(int_from_bytes(sig[0:32]))
    assert(not has_square_y(R))
    return (seckey, pubkey, aux_rand, msg, sig, "TRUE", None)
@ -47,7 +47,7 @@ def vector1():
    sig = schnorr_sign(msg, seckey, aux_rand)
    # The point reconstructed from the R.x coordinate has a square Y coordinate.
-    R = lift_x(sig[0:32])
+    R = lift_x(int_from_bytes(sig[0:32]))
    assert(has_square_y(R))
    return (seckey, pubkey_gen(seckey), aux_rand, msg, sig, "TRUE", None)
@ -60,12 +60,12 @@ def vector2():
    # The point reconstructed from the public key has a square Y coordinate.
    pubkey = pubkey_gen(seckey)
-    pubkey_point = lift_x(pubkey)
+    pubkey_point = lift_x(int_from_bytes(pubkey))
    assert(has_square_y(pubkey_point))
    # This signature vector would not verify if the implementer checked the
    # evenness of the X coordinate of R instead of the Y coordinate.
-    R = lift_x(sig[0:32])
+    R = lift_x(int_from_bytes(sig[0:32]))
    assert(R[0] % 2 == 1)
    return (seckey, pubkey, aux_rand, msg, sig, "TRUE", None)
@ -99,7 +99,7 @@ def insecure_schnorr_sign_fixed_nonce(msg, seckey0, k):
    e = int_from_bytes(tagged_hash("BIP0340/challenge", bytes_from_point(R) + bytes_from_point(P) + msg)) % n
    return bytes_from_point(R) + bytes_from_int((k + e * seckey) % n)
-# Creates a singature with a small x(R) by using k = -1/2
+# Creates a signature with a small x(R) by using k = -1/2
 def vector4():
    one_half = n - 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0
    seckey = bytes_from_int(0x763758E5CBEEDEE4F7D3FC86F531C36578933228998226672F13C4F0EBE855EB)
@ -119,8 +119,9 @@ def vector5():
    msg = default_msg
    sig = schnorr_sign(msg, seckey, default_aux_rand)
-    pubkey = bytes_from_int(0xEEFDEA4CDB677750A420FEE807EACF21EB9898AE79B9768766E4FAA04A2D4A34)
+    pubkey_int = 0xEEFDEA4CDB677750A420FEE807EACF21EB9898AE79B9768766E4FAA04A2D4A34
-    assert(lift_x(pubkey) is None)
+    pubkey = bytes_from_int(pubkey_int)
    assert(lift_x(pubkey_int) is None)
    return (None, pubkey, None, msg, sig, "FALSE", "public key not on the curve")
@ -197,9 +198,9 @@ def vector11():
    sig = schnorr_sign(msg, seckey, default_aux_rand)
    # Replace R's X coordinate with an X coordinate that's not on the curve
-    x_not_on_curve = bytes_from_int(0x4A298DACAE57395A15D0795DDBFD1DCB564DA82B0F269BC70A74F8220429BA1D)
+    x_not_on_curve = 0x4A298DACAE57395A15D0795DDBFD1DCB564DA82B0F269BC70A74F8220429BA1D
    assert(lift_x(x_not_on_curve) is None)
-    sig = x_not_on_curve + sig[32:64]
+    sig = bytes_from_int(x_not_on_curve) + sig[32:64]
    return (None, pubkey_gen(seckey), None, msg, sig, "FALSE", "sig[0:32] is not an X coordinate on the curve")
@ -242,10 +243,10 @@ def vector14():
    sig = schnorr_sign(msg, seckey, default_aux_rand)
    pubkey_int = p + 1
    pubkey = bytes_from_int(pubkey_int)
-    assert(lift_x(pubkey) is None)
+    assert(lift_x(pubkey_int) is None)
    # If an implementation would reduce a given public key modulo p then the
    # pubkey would be valid
-    assert(lift_x(bytes_from_int(pubkey_int % p)) is not None)
+    assert(lift_x(pubkey_int % p) is not None)
    return (None, pubkey, None, msg, sig, "FALSE", "public key is not a valid X coordinate because it exceeds the field size")
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@ -41,7 +41,7 @@ As a result we choose this combination of technologies:
 * '''Taproot''' on top of that lets us merge the traditionally separate pay-to-pubkey and pay-to-scripthash policies, making all outputs spendable by either a key or (optionally) a script, and indistinguishable from each other. As long as the key-based spending path is used for spending, it is not revealed whether a script path was permitted as well, resulting in space savings and an increase in scripting privacy at spending time.
 * Taproot's advantages become apparent under the assumption that most applications involve outputs that could be spent by all parties agreeing. That's where '''Schnorr''' signatures come in, as they permit [https://eprint.iacr.org/2018/068 key aggregation]: a public key can be constructed from multiple participant public keys, and which requires cooperation between all participants to sign for. Such multi-party public keys and signatures are indistinguishable from their single-party equivalents. This means that with taproot most applications can use the key-based spending path, which is both efficient and private. This can be generalized to arbitrary M-of-N policies, as Schnorr signatures support threshold signing, at the cost of more complex setup protocols.
 * As Schnorr signatures also permit '''batch validation''', allowing multiple signatures to be validated together more efficiently than validating each one independently, we make sure all parts of the design are compatible with this.
-* Where unused bits appear as a result of the above changes, they are reserved for mechanisms for '''future extensions'''. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused <code>annex</code> in the witness (see [[bip-0341.mediawiki#Rationale|BIP341]]).
+* Where unused bits appear as a result of the above changes, they are reserved for mechanisms for '''future extensions'''. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused <code>annex</code> in the witness (see [[bip-0341.mediawiki#rationale|Rationale]]).
 * While the core semantics of the '''signature hashing algorithm''' are not changed, a number of improvements are included in this proposal. The new signature hashing algorithm fixes the verification capabilities of offline signing devices by including amount and scriptPubKey in the signature message, avoids unnecessary hashing, uses '''tagged hashes''' and defines a default sighash byte.
 * The '''public key is directly included in the output''' in contrast to typical earlier constructions which store a hash of the public key or script in the output. This has the same cost for senders and is more space efficient overall if the key-based spending path is taken. <ref>'''Why is the public key directly included in the output?''' While typical earlier constructions store a hash of a script or a public key in the output, this is rather wasteful when a public key is always involved. To guarantee batch verifiability, the public key must be known to every verifier, and thus only revealing its hash as an output would imply adding an additional 32 bytes to the witness. Furthermore, to maintain [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html 128-bit collision security] for outputs, a 256-bit hash would be required anyway, which is comparable in size (and thus in cost for senders) to revealing the public key directly. While the usage of public key hashes is often said to protect against ECDLP breaks or quantum computers, this protection is very weak at best: transactions are not protected while being confirmed, and a very [https://twitter.com/pwuille/status/1108097835365339136 large portion] of the currency's supply is not under such protection regardless. Actual resistance to such systems can be introduced by relying on different cryptographic assumptions, but this proposal focuses on improvements that do not change the security model.</ref>
@ -136,6 +136,8 @@ In summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types rem
 ==== Taproot key path spending signature validation ====
 A Taproot signature is a 64-byte Schnorr signature, as defined in [[bip-0340.mediawiki|BIP340]], with the sighash byte appended in the usual Bitcoin fashion. This sighash byte is optional. If omitted, the resulting signatures are 64 bytes, and a SIGHASH_DEFAULT mode is implied.
 To validate a signature ''sig'' with public key ''q'':
 * If the ''sig'' is 64 bytes long, return ''Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(0x00, 0)), sig)''<ref>'''Why is the input to ''hash<sub>TapSighash</sub>'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hash<sub>TapSighash</sub>'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.</ref>, where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]].
 * If the ''sig'' is 65 bytes long, return ''sig[64] &ne; 0x00<ref>'''Why can the <code>hash_type</code> not be <code>0x00</code> in 65-byte signatures?''' Permitting that would enable malleating (by third parties, including miners) 64-byte signatures into 65-byte ones, resulting in a different `wtxid` and a different fee rate than the creator intended.</ref> and Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(sig[64], 0)), sig[0:64])''.
--- a/bip-0343.mediawiki
+++ b/bip-0343.mediawiki
@ -19,7 +19,7 @@ This document specifies a BIP8 (LOT=true) deployment to activate taproot.
 ==Motivation==
-The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus. 
+The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus.
 ==Specification==
--- a/bip-0345.mediawiki
+++ b/bip-0345.mediawiki
@ -4,13 +4,12 @@
  Title: OP_VAULT
  Author: James O'Beirne <vaults@au92.org>
          Greg Sanders <gsanders87@gmail.com>
          Anthony Towns <aj@erisian.com.au>
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0345
  Status: Draft
  Type: Standards Track
  Created: 2023-02-03
  License: BSD-3-Clause
-  Post-History: 2023-01-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [bitcoin-dev] OP_VAULT announcment
+  Post-History: 2023-01-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [bitcoin-dev] OP_VAULT announcement
                2023-03-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021510.html [bitcoin-dev] BIP for OP_VAULT
 </pre>
@ -52,23 +51,23 @@ A common configuration for an individual custodying Bitcoin is "single
 signature and passphrase" using a hardware wallet. A user with such a
 configuration might be concerned about the risk associated with relying on a
 single manufacturer for key management, as well as physical access to the
-hardware. 
+hardware.
 This individual can use <code>OP_VAULT</code> to make use of a highly secure
 key as the unlikely recovery path, while using their existing signing procedure
-as the withdrawal trigger key with a configured spend delay of e.g. 1 day. 
+as the withdrawal trigger key with a configured spend delay of e.g. 1 day.
 The recovery path key can be of a highly secure nature that might otherwise
 make it impractical for daily use. For example, the key could be generated in
 some analog fashion, or on an old computer that is then destroyed, with the
 private key replicated only in paper form. Or the key could be a 2-of-3
 multisig using devices from different manufacturers. Perhaps the key is
-geographically or socially distributed. 
+geographically or socially distributed.
 Since it can be any Bitcoin script policy, the recovery key can include a
 number of spending conditions, e.g. a time-delayed fallback to an "easier"
 recovery method, in case the highly secure key winds up being ''too'' highly
-secure. 
+secure.
 The user can run software on their mobile device that monitors the blockchain
 for spends of the vault outpoints. If the vaulted coins move in an unexpected
@ -80,7 +79,7 @@ Institutional custodians of Bitcoin may use vaults in similar fashion.
 ===== Provable timelocks =====
-This proposal provides a mitigation to the 
+This proposal provides a mitigation to the
 [https://web.archive.org/web/20230210123933/https://xkcd.com/538/ "$5 wrench attack."] By
 setting the spend delay to, say, a week, and using as the recovery path a
 script that enforces a longer relative timelock, the owner of the vault can
@ -95,7 +94,7 @@ timelocked coins for perpetuity or relying on a trusted third party.
 Vaults in Bitcoin have been discussed formally since 2016
 ([http://fc16.ifca.ai/bitcoin/papers/MES16.pdf MES16]) and informally since [https://web.archive.org/web/20160220215151/https://bitcointalk.org/index.php?topic=511881.0 2014]. The value of
 having a configurable delay period with recovery capability in light of an
-unexpected spend has been widely recognized. 
+unexpected spend has been widely recognized.
 The only way to implement vaults given the existing consensus rules, aside from
 [https://github.com/revault emulating vaults with large multisig
@ -114,7 +113,7 @@ Unfortunately, this approach has a number of practical shortcomings:
 The deployment of a "precomputed" covenant mechanism like
 [https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki OP_CHECKTEMPLATEVERIFY] or
-[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT] 
+[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT]
 would both remove the necessity to use an ephemeral key, since the
 covenant is enforced on-chain, and lessen the burden of sensitive data storage,
 since the necessary transactions can be generated from a set of compact
@ -141,7 +140,7 @@ operational overhead using a specialized covenant.
 The design goals of the proposal are:
-* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits. 
+* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits.
 * '''batched operations''' for recovery and withdrawal to allow managing multiple vault coins efficiently.
@ -163,7 +162,7 @@ In typical usage, a vault is created by encumbering coins under a
 taptree [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki (BIP-341)]
 containing at least two leaves: one with an <code>OP_VAULT</code>-containing script that
 facilitates the expected withdrawal process, and another leaf with
-<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered 
+<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered
 at any time prior to withdrawal finalization.
 The rules of <code>OP_VAULT</code> ensure the timelocked, interruptible
@ -172,7 +171,7 @@ withdrawal by allowing a spending transaction to replace the
 some parameters to be set at spend (trigger) time. All other leaves in the
 taptree must be unchanged in the destination output, which preserves the recovery path as well as any
 other spending conditions originally included in the vault. This is similar to
-the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed 
+the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed
 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html in 2021].
 These tapleaf replacement rules, described more precisely below, ensure a
@ -205,14 +204,14 @@ The vault has a number of stages, some of them optional:
 === Fee management ===
 A primary consideration of this proposal is how fee management is handled.
-Providing dynamic fee management is critical to the operation of a vault, since 
+Providing dynamic fee management is critical to the operation of a vault, since
 * precalculated fees are prone to making transactions unconfirmable in high fee environments, and
 * a fee wallet that is prespecified might be compromised or lost before use.
 But dynamic fee management can introduce
 [https://bitcoinops.org/en/topics/transaction-pinning/ pinning vectors]. Care
-has been taken to avoid unnecessarily introducing these vectors when using the new 
+has been taken to avoid unnecessarily introducing these vectors when using the new
 destination-based spending policies that this proposal introduces.
 Originally, this proposal had a hard dependency on reformed transaction
@ -237,7 +236,7 @@ When evaluating <code>OP_VAULT</code> (<code>OP_SUCCESS187</code>,
 <leaf-update-script-body>
 <push-count>
 [ <push-count> leaf-update script data items ... ]
-<trigger-vout-idx> 
+<trigger-vout-idx>
 <revault-vout-idx>
 <revault-amount>
 </source>
@ -290,7 +289,7 @@ If none of the conditions fail, a single true value (<code>0x01</code>) is left
 === <code>OP_VAULT_RECOVER</code> evaluation ===
 When evaluating <code>OP_VAULT_RECOVER</code> (<code>OP_SUCCESS188</code>,
-<code>0xbb</code>), the expected format of the stack, shown top to bottom, is:
+<code>0xbc</code>), the expected format of the stack, shown top to bottom, is:
 <source>
 <recovery-sPK-hash>
@ -413,10 +412,10 @@ that contains a taptree of the form
 <source>
 tr(<internal-pubkey>,
  leaves = {
-    recover: 
+    recover:
      <recovery-sPK-hash> OP_VAULT_RECOVER,
-    trigger: 
+    trigger:
      <trigger-auth-pubkey> OP_CHECKSIGVERIFY                     (i)
      <spend-delay> 2 $leaf-update-script-body OP_VAULT,          (ii)
@ -434,7 +433,7 @@ Typically, the internal key for the vault taproot output will be specified so
 that it is controlled by the same descriptor as the recovery path, which
 facilitates another (though probably unused) means of recovering the vault
 output to the recovery path. This has the potential advantage of recovering the
-coin without ever revealing it was a vault. 
+coin without ever revealing it was a vault.
 Otherwise, the internal key can be chosen to be an unspendable NUMS point to
 force execution of the taptree contents.
@ -442,7 +441,7 @@ force execution of the taptree contents.
 === Triggering a withdrawal ===
 To make use of the vault, and spend it towards some output, we construct a spend
-of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the 
+of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the
 full leaf-update script (in this case, a timelocked CTV script):
 <source>
@ -461,17 +460,17 @@ Output scripts:
 [
  tr(<internal-pubkey>,
    leaves = {
-      recover: 
+      recover:
        <recovery-sPK-hash> OP_VAULT_RECOVER,               <--  unchanged
      trigger:
-        <target-CTV-hash> <spend-delay> 
+        <target-CTV-hash> <spend-delay>
-        OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY  <--  changed per the 
+        OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY  <--  changed per the
                                                                    leaf-update
                                                                    rules of OP_VAULT
       ... [ possibly other leaves ]
     }
-   ),                                                               
+   ),
   [ optional revault output with the
     same sPK as the original vault output ],
@ -499,7 +498,7 @@ entails trade-offs.
 ==== Unauthorized recovery ====
-Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>. 
+Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>.
 But because this reveal is the only authorization necessary to spend the vault coins to recovery, the user must expect to recover all such vaults at once, since an observer can replay this recovery (provided they know the outpoints).
@ -513,7 +512,7 @@ These limitations are to avoid pinning attacks.
 ==== Authorized recovery ====
-With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required. 
+With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required.
 If this key is lost, the user will be unable to initiate the recovery process for their coins. If an attacker obtains the recovery key, they may grief the user during the recovery process by constructing a low fee rate recovery transaction and broadcasting it (though they will not be able to pin because of the replaceability requirement on recovery transactions).
@ -521,7 +520,7 @@ However, authorized recovery configurations have significant benefits. Batched r
 ==== Recommendation: use a simple, offline recovery authorization key seed ====
-The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated. 
+The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated.
 Note that the recovery authorization key '''is not''' the recovery path key, and
 this is '''much different''' than any recommendation on how to generate the
@ -542,7 +541,7 @@ the trigger authorization pubkeys.
 Note that when using unauthorized recovery, the reveal of the
 recovery scriptPubKey will allow any observer to initiate the recovery process
 for any vault with matching recovery params, provided they are able to locate
-the vault outpoints. As a result, it is recommended to expect that 
+the vault outpoints. As a result, it is recommended to expect that
 '''all outputs sharing an identical unauthorized <code><recovery-sPK-hash></code> should be recovered together'''.
 This situation can be avoided with a comparable key management model by varying
@ -589,7 +588,7 @@ are essentially dependent on v3 transaction relay policy being deployed.
 <code>OP_VAULT</code> outputs with the same taptree, aside from slightly
 different trigger leaves, can be batched together in the same withdrawal
-process. Two "trigger" leaves are compatible if they have the same 
+process. Two "trigger" leaves are compatible if they have the same
 <code>OP_VAULT</code> arguments.
 Note that this allows the trigger authorization -- the script prefixing the
@ -617,7 +616,7 @@ can be recovered into the same output.
 Recovery-incompatible vaults which have authorized recovery can be recovered in
 the same transaction, so long as each set (grouped by
-<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows 
+<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows
 unrelated recoveries to share common fee management.
 === Watchtowers ===
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@ -0,0 +1,113 @@
 <pre>
  BIP: 347
  Layer: Consensus (soft fork)
  Title: OP_CAT in Tapscript
  Author: Ethan Heilman <ethan.r.heilman@gmail.com>
          Armin Sabouri <arminsdev@gmail.com>
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0347
  Status: Draft
  Type: Standards Track
  Created: 2023-12-11
  License: BSD-3-Clause
  Post-History: 2023-10-21: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html [bitcoin-dev] Proposed BIP for OP_CAT
 </pre>
 ==Abstract==
 This BIP introduces OP_CAT as a tapscript opcode which allows the concatenation of two values on the stack. OP_CAT would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal). This is the same opcode value used by the original OP_CAT.
 == Copyright ==
 This document is licensed under the 3-clause BSD license.
 ==Specification==
 When evaluated, the OP_CAT instruction:
 # Pops the top two values off the stack,
 # concatenates the popped values together in stack order,
 # and then pushes the concatenated value on the top of the stack.
 Given the stack ''<nowiki>[x1, x2]</nowiki>'', where ''x2'' is at the top of the stack, OP_CAT will push ''x1 || x2'' onto the stack. By ''||'' we denote concatenation. OP_CAT fails if there are fewer than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 bytes.
 This opcode would be activated via a soft fork by redefining the tapscript opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal) to OP_CAT.
 ==Motivation==
 Bitcoin Tapscript lacks a general purpose way of combining objects on the stack, restricting the expressiveness and power of Tapscript. This prevents, among many other things, the ability to construct and evaluate merkle trees and other hashed data structures in Tapscript. OP_CAT, by adding a general purpose way to concatenate stack values, would overcome this limitation and greatly increase the functionality of Tapscript.
 OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix <ref>R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf</ref>. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT, they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. <ref>R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf</ref>
 * Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions. <ref> P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/</ref>
 * Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. <ref>J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html</ref> It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as "script-path only" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.
 * Non-equivocation contracts <ref>T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://web.archive.org/web/20221023121048/https://publications.cispa.saarland/565/1/penalizing.pdf</ref> in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults <ref>M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf</ref> which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in <ref>A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html</ref> OP_CAT is sufficient to build vaults in Bitcoin.
 * Replicating CheckSigFromStack <ref>A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html</ref> which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures <ref>R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md</ref>.
 OP_CAT was available in early versions of Bitcoin.
 In 2010, a single commit disabled OP_CAT, along with another 15 opcodes.
 Folklore states that OP_CAT was removed in this commit because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
 For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack element whose size was greater than 1 terabyte assuming no maximum stack element size. As Bitcoin at that time had a maximum stack element size of 5000 bytes, the effect of this expansion was limited to 5000 bytes.
 This is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes.
 ==Rationale==
 Our decision to reenable OP_CAT by redefining a tapscript OP_SUCCESSx opcode to OP_CAT was motivated to leverage the tapscript softfork opcode upgrade path introduced in [[bip-0342.mediawiki|BIP342]].
 We specifically choose to use OP_SUCCESS126 rather than another OP_SUCCESSx as OP_SUCCESS126 uses the same opcode value (126 in decimal and 0x7e in hexadecimal) that was used for OP_CAT prior to it being disabled in Bitcoin. This removes a potential source of confusion that would exist if we had a opcode value different from the one used in the original OP_CAT opcode.
 While the OP_SUCCESSx opcode upgrade path could enable us to increase the stack element size while reenabling OP_CAT, we wanted to separate the decision to change the stack element size limit from the decision to reenable OP_CAT. This BIP takes no position in favor or against increasing the stack element size limit.
 ==Backwards Compatibility==
 OP_CAT usage in a non-tapscript script will continue to trigger the SCRIPT_ERR_DISABLED_OPCODE. The only change would be to OP_CAT usage in tapscript. This change to tapscript would be activated as a soft fork that redefines an OP_SUCCESSx opcode (OP_SUCCESS126) to OP_CAT.
 ==Reference implementation==
 <pre>
 case OP_CAT:
 {
  if (stack.size() < 2)
    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
  valtype& vch1 = stacktop(-2);
  valtype& vch2 = stacktop(-1);
  if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
    return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
  vch1.insert(vch1.end(), vch2.begin(), vch2.end());
  stack.pop_back();
 }
 break;
 </pre>
 The value of <code>MAX_SCRIPT_ELEMENT_SIZE</code> is 520.
 This implementation is inspired by the original implementation of [https://github.com/bitcoin/bitcoin/blob/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e/script.cpp#L381-L393 OP_CAT as it existed in the Bitcoin codebase] prior to the commit "misc changes" 4bd188c<ref>S. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94</ref> which disabled it:
 <pre>
 case OP_CAT:
 {
    // (x1 x2 -- out)
    if (stack.size() < 2)
        return false;
    valtype& vch1 = stacktop(-2);
    valtype& vch2 = stacktop(-1);
    vch1.insert(vch1.end(), vch2.begin(), vch2.end());
    stack.pop_back();
    if (stacktop(-1).size() > 5000)
        return false;
 }
 break;
 </pre>
 An alternative implementation of OP_CAT can be found in Elements <ref>Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759</ref>.
 ==References==
 <references/>
 ==Acknowledgements==
 We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill,
 Tim Ruffing and Johan T. Halseth for their feedback, review and helpful comments.
--- a/bip-0348.md
+++ b/bip-0348.md
@ -0,0 +1,142 @@
 <pre>
  BIP: 348
  Layer: Consensus (soft fork)
  Title: CHECKSIGFROMSTACK
  Author: Brandon Black <freedom@reardencode.com>
          Jeremy Rubin <j@rubin.io>
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0348
  Status: Draft
  Type: Standards Track
  Created: 2024-11-26
  License: BSD-3-Clause
 </pre>
 ## Abstract
 This BIP describes a new opcode for the purpose of checking cryptographic
 signatures in bitcoin scripts against data from the stack.
 ## Summary
 When verifying taproot script spends having leaf version 0xc0 (as defined in
 [BIP 342]), we propose `OP_CHECKSIGFROMSTACK` to replace `OP_SUCCESS204`
 (0xcc).
 `OP_CHECKSIGFROMSTACK` has semantics similar to `OP_CHECKSIG`, as specified
 below. Briefly, it pops 3 elements from the stack: a 32-byte public key, a
 message, and a signature. If the signature is valid for that public key and
 message, 1 is pushed to the stack. If the signature is the empty vector, 0 is
 pushed to the stack, and otherwise script execution fails.
 Only 32-byte keys are constrained. Similar to [BIP 341] unknown key types, for
 other key lengths no signature verification is performed and it is considered
 successful.
 ## Specification
 * If fewer than 3 elements are on the stack, the script MUST fail and terminate immediately.
 * The public key (top element), message (second to top element), and signature (third from top element) are read from the stack.
 * The top three elements are popped from the stack.
 * If the public key size is zero, the script MUST fail and terminate immediately.
 * If the public key size is 32 bytes, it is considered to be a public key as described in [BIP 340]:
    * If the signature is not the empty vector, the signature is validated against the public key and message according to [BIP 340]. Validation failure in this case immediately terminates script execution with failure.
 * If the public key size is not zero and not 32 bytes; the public key is of an unknown public key type. Signature verification for unknown public key types succeeds as if signature verification for a known public key type had succeeded.
 * If the script did not fail and terminate before this step, regardless of the public key type:
    * If the signature is the empty vector: An empty vector is pushed onto the stack, and execution continues with the next opcode.
    * If the signature is not the empty vector:
        * The opcode is counted towards the sigops budget as described in [BIP 342].
        * A 1-byte value 0x01 is pushed onto the stack.
 ## Design Considerations
 1. Message hashing: [BIP 340] is compatible with any size of message and does not require it to be a securely hashed input, so the message is not hashed prior to [BIP 340] verification.
 2. Lack of verify semantics: Adding a single opcode for this purpose keeps the implementation and design simple. An earlier draft had a verify variant as a NOP upgrade, and if this functionality is later brought to legacy scripts, that would be a good time to add a verify variant.
 3. Add/multisig: No concession is made to `OP_CHECKMULTISIG` or `OP_CHECKSIGADD` semantics with `OP_CHECKSIGFROMSTACK`. In Tapscript, add semantics can be implemented with 1 additional vByte per key (`OP_TOALTSTACK OP_CHECKSIGFROMSTACK OP_FROMALTSTACK OP_ADD`).
 4. Splitting R/S on the stack: Implementing split/separate signatures is left as an exercise for other bitcoin upgrades, such as [BIP 347] (`OP_CAT`).
 5. APO-style ([BIP 118]) Taproot internal key: Rather than introducing an additional key type in this change, we suggest implementing `OP_INTERNALKEY` ([BIP 349]) or separately introducing that key type for all Tapscript signature checking operations in a separate change.
 ## Resource Limits
 These opcodes are treated identically to other signature checking opcodes and
 count against the sigops and budget.
 ## Motivation
 ### LN Symmetry
 When combined with [BIP 119] (`OP_CHECKTEMPLATEVERIFY`/CTV),
 `OP_CHECKSIGFROMSTACK` (CSFS) can be used to implement Lightning Symmetry
 channels. The construction `OP_CHECKTEMPLATEVERIFY <pubkey>
 OP_CHECKSIGFROMSTACK` with a spend stack containing the CTV hash and a
 signature for it is logically equivalent to `<bip118_pubkey> OP_CHECKSIG` and
 a signature over `SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT`. The
 `OP_CHECKSIGFROMSTACK` construction is 8 vBytes larger.
 Summary of alternatives:
 * CTV+CSFS is the minimal functionality needed for Lightning Symmetry but requires the use of an `OP_RETURN` for data availability
 * APO is the original design for Lightning Symmetry and uses the taproot annex for data availability.
 * LNHANCE (CTV+CSFS+IKEY+PC) is the most efficient and direct way currently designed to implement Lightning Symmetry.
 ### Delegation
 Using a script like:
 `<pubkey> SWAP IF 2 PICK SWAP CSFS VERIFY ENDIF CHECKSIG`
 either direct verification or delegation can be achieved by the following
 unlock stacks: `<sig> 0` or `<dsig> <dpubkey> <sig> 1`
 ### Advanced delegation when combined with [OP_PAIRCOMMIT] or OP_CAT
 Using a script like:
 `CLTV OVER PAIRCOMMIT TOALT CHECKSIGVERIFY FROMALT <pubkey> CSFS`
 or:
 `CLTV SHA256 OVER CAT TOALT CHECKSIGVERIFY FROMALT <pubkey> CSFS`
 with the unlock stack:
 `<sig> <delegate_sig> <delegate_pubkey> <locktime>`
 Delegates to a public key after a lock time, enabling delegation to various
 keys after various associated times.
 ## Reference Implementation
 A reference implementation is provided here:
 https://github.com/bitcoin/bitcoin/pull/29270
 ## Backward Compatibility
 By constraining the behavior of an OP_SUCCESS opcode,
 deployment of the BIP can be done in a backwards compatible, soft-fork manner.
 If anyone were to rely on the OP_SUCCESS behavior of
 `OP_SUCCESS204`, `OP_CHECKSIGFROMSTACK` would invalidate
 their spend.
 ## Deployment
 TBD
 ## Credits
 Reference implementation was made with reference to the implementation in
 Elements and started by moonsettler.
 ## Copyright
 This document is licensed under the 3-clause BSD license.
 [BIP 119]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
 [BIP 118]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
 [BIP 340]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
 [BIP 341]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
 [BIP 342]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
 [BIP 349]: https://github.com/bitcoin/bips/blob/master/bip-0349.md
 [BIP 347]: https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki
 [OP_PAIRCOMMIT]: https://github.com/bitcoin/bips/pull/1699
 [mailing list]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019192.html
--- a/Show more
+++ b/Show more
`@ -69,4 +69,4 @@ bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe`

	`==References==`	`==References==`

	`[[http://www.w3.org/Protocols/rfc2616/rfc2616.html\|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1`	`[[http://www.w3.org/Protocols/rfc2616/rfc2616.html\|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1`
		`@ -1 +0,0 @@`
			`Images used as reference in the documentation.`