Merge branch 'bitcoin:master' into ccv

Author: bigspider

README.mediawiki

@@ -27,13 +27,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Luke Dashjr
 | Process
 | Active
-|-
+|- style="background-color: #ffffcf"
 | [[bip-0003.md|3]]
 |
 | Updated BIP Process
 | Murch
 | Process
-| Draft
+| Proposed
 |-
 | [[bip-0008.mediawiki|8]]
 |
@@ -300,14 +300,21 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Michael Dubrovsky, Bogdan Penkovsky
 | Standard
 | Draft
-<!-- 50 series reserved for a group of post-mortems -->
 |-
+| [[bip-0054.md|54]]
+| Consensus (soft fork)
+| Consensus Cleanup
+| Antoine Poinsot, Matt Corallo
+| Standard
+| Draft
+<!-- 50 series reserved for a group of post-mortems -->
+|- style="background-color: #ffcfcf"
 | [[bip-0060.mediawiki|60]]
 | Peer Services
 | Fixed Length "version" Message (Relay-Transactions Field)
 | Amir Taaki
 | Standard
-| Draft
+| Rejected
 |- style="background-color: #cfffcf"
 | [[bip-0061.mediawiki|61]]
 | Peer Services
@@ -910,6 +917,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Luke Dashjr
 | Standard
 | Rejected
+|-
+| [[bip-0172.mediawiki|172]]
+| Applications
+| Define Bitcoin Subunits as Satoshis
+| OceanSlim
+| Informational
+| Draft
 |- style="background-color: #cfffcf"
 | [[bip-0173.mediawiki|173]]
 | Applications
@@ -939,6 +953,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |-
+| [[bip-0177.mediawiki|177]]
+|
+| Redefine Bitcoin's Base Unit
+| John Carvalho
+| Informational
+| Draft
+|-
 | [[bip-0178.mediawiki|178]]
 | Applications
 | Version Extended WIF
@@ -966,13 +987,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Matthew Black, Tony Cai
 | Standard
 | Draft
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0199.mediawiki|199]]
 | Applications
 | Hashed Time-Locked Contract transactions
 | Sean Bowe, Daira Hopwood
 | Standard
-| Draft
+| Rejected
 |-
 | [[bip-0300.mediawiki|300]]
 | Consensus (soft fork)
@@ -1002,6 +1023,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0321.mediawiki|321]]
+| Applications
+| URI Scheme
+| Matt Corallo
+| Standard
+| Draft
+|-
 | [[bip-0322.mediawiki|322]]
 | Applications
 | Generic Signed Message Format
@@ -1113,13 +1141,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Shinobius, Michael Folkson
 | Standard
 | Final
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0345.mediawiki|345]]
 | Consensus (soft fork)
 | OP_VAULT
 | James O'Beirne, Greg Sanders
 | Standard
-| Draft
+| Withdrawn
 |-
 | [[bip-0347.mediawiki|347]]
 | Consensus (soft fork)

bip-0003.md

@@ -3,7 +3,7 @@
   Title: Updated BIP Process
   Author: Murch <[email protected]>
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0003
-  Status: Draft
+  Status: Proposed
   Type: Process
   Created: 2025-01-09
   License: BSD-2-Clause
@@ -75,7 +75,7 @@ allows any community member to retain a complete copy of the archive easily.
 The BIPs repository is not a tool to track acceptance[^acceptance], adoption, or community consensus on BIPs, beyond
 providing a brief overview of BIP statuses (see [Workflow](#workflow) below) to the audience.
 There is no formal or informal decision body that governs Bitcoin development or decides acceptance of BIPs. Bitcoin
-development emerges from the participation of shareholders across the ecosystem.
+development emerges from the participation of stakeholders across the ecosystem.
 
 ## BIP Format and Structure
 
@@ -96,7 +96,7 @@ following list and address each as appropriate.
 * Rationale — The rationale fleshes out the specification by describing what inspired the design and why particular
   design decisions were made. It should describe related work and alternate designs that were considered. The rationale
   should record relevant objections or important concerns that were raised and addressed as this proposal was developed.
-* Backward Compatibility — Any BIP that introduces incompatibilities must include a section describing these incompatibities and their severity as well as provide instructions on how
+* Backward Compatibility — Any BIP that introduces incompatibilities must include a section describing these incompatibilities and their severity as well as provide instructions on how
   implementers and users should deal with these incompatibilities.
 * Reference Implementation — Where applicable, a reference implementation, test vectors, and documentation must be
   finished before the BIP can be given the status "Complete". Test vectors must be provided in the BIP or
@@ -305,7 +305,7 @@ to Closed unless the authors assert that they intend to continue work within fou
 
 BIPs that had attained the Complete status, i.e., that had been recommended for adoption, may be moved to Closed per the
 authors’ announcement to the Bitcoin Development Mailing List[^bip-announcements-to-list]. However, if someone volunteers to adopt the proposal
-within four weeks, they become the BIP's author or deputy, and the BIP will
+within four weeks, they become the BIP's author or deputy (see [Transferring BIP Ownership](#transferring-bip-ownership) below), and the BIP will
 remain Complete instead.
 
 ##### Deployed ↦ Closed
@@ -561,7 +561,7 @@ This BIP replaces BIP 2 as the guideline for the BIP process.
 #### BIP Types
 
 Standards Track BIPs and eligible Informational BIPs are assigned the Specification type. The Standards Track type is
-considered obsolete. Specification BIPs use the Layer header rules specified in [BIP 123](BIP-0123.mediawiki).
+considered obsolete. Specification BIPs use the Layer header rules specified in [BIP 123](bip-0123.mediawiki).
 
 #### Comments
 
@@ -596,13 +596,13 @@ The licenses of existing BIPs remain untouched.
 ## Copyright
 
 This BIP is licensed under the [BSD-2-Clause License](https://opensource.org/licenses/BSD-2-Clause). Some content was
-adapted from [BIP 2](BIP-0002.mediawiki) which was also licensed under the BSD-2-Clause.
+adapted from [BIP 2](bip-0002.mediawiki) which was also licensed under the BSD-2-Clause.
 
 ## Related Work
 
 - [BIP 1: BIP Purpose and Guidelines](bip-0001.mediawiki)
-- [BIP 2: BIP Process, revised](BIP-0002.mediawiki)
-- [BIP 123: BIP Classification](BIP-0123.mediawiki)
+- [BIP 2: BIP Process, revised](bip-0002.mediawiki)
+- [BIP 123: BIP Classification](bip-0123.mediawiki)
 - [RFC 822: Standard for ARPA Internet Text Messages](https://datatracker.ietf.org/doc/html/rfc822)
 - [RFC 2223: Instructions to RFC Authors](https://datatracker.ietf.org/doc/html/rfc2223)
 - [RFC 7282: On Consensus and Humming in the IETF](https://tools.ietf.org/html/rfc7282)
@@ -686,7 +686,7 @@ feedback, and helpful comments.
     raised that making announcements to the Bitcoin Developer Mailing List would introduce unnecessary noise, our
     rationale is that 1) moving Complete and Deployed BIPs to the Closed status will be a rare occurrence, 2) status
     updates will usually not generate a lot of discussion, 3) while the mailing list should preferably only used for
-    getting review for new BIPs, it is the only channel available to us that can be consider a public announcement to
+    getting review for new BIPs, it is the only channel available to us that can be considered a public announcement to
     the audience of the BIPs repository: even if the authors, implementers, or other parties interested in a BIP do not
     see the announcement themselves, they may be made aware by someone that does see it.
 [^superseded-by-proposed-replacement]: **Why is Superseded-By replaced with Proposed-Replacement?**  

bip-0015.mediawiki

@@ -12,7 +12,7 @@
 
 [[bip-0070.mediawiki|BIP 0070]] (payment protocol) may be seen as the alternative to Aliases.
 
-Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.
+Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is that they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.
 
 This document aims to layout through careful argument, a bitcoin alias system. This is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure.
 

bip-0020.mediawiki

@@ -54,7 +54,7 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit
 
 *label: Label for that address (e.g. name of receiver)
 *address: bitcoin address
-*message: message that shown to the user after scanning the QR code
+*message: message that is shown to the user after scanning the QR code
 *size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
 *send: used to send bitcoin, rather than to request them
 *(others): optional, for future extensions

bip-0032.mediawiki

@@ -137,7 +137,7 @@ Extended public and private keys are serialized as follows:
 * 32 bytes: the chain code
 * 33 bytes: the public key or private key data (ser<sub>P</sub>(K) for public keys, 0x00 || ser<sub>256</sub>(k) for private keys)
 
-This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of up to 112 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet.
+This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of exactly 111 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet.
 
 Note that the fingerprint of the parent only serves as a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.
 

bip-0035.mediawiki

@@ -24,7 +24,7 @@ Several use cases make it desirable to expose a network node's transaction memor
 ==Specification==
 
 # The mempool message is defined as an empty message where pchCommand == "mempool"
-# Upon receipt of a "mempool" message, the node will respond   with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any.
+# Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any.
 # The typical node behavior in response to an "inv" is "getdata". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support "mempool", an implementation must extend its "getdata" message support to querying the memory pool.
 # Feature discovery is enabled by checking two "version" message attributes:
 ## Protocol version >= 60002

bip-0037.mediawiki

@@ -159,7 +159,7 @@ A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in
 ** Check whether this node corresponds to a leaf node (transaction) that is to be included OR any parent thereof:
 *** If so, append a '1' bit to the flag bits
 *** Otherwise, append a '0' bit.
-** Check whether this node is a internal node (non-leaf) AND is the parent of an included leaf node:
+** Check whether this node is an internal node (non-leaf) AND is the parent of an included leaf node:
 *** If so:
 **** Descend into its left child node, and process the subtree beneath it entirely (depth-first).
 **** If this node has a right child node too, descend into it as well.

bip-0039/bip-0039-wordlists.md

@@ -50,7 +50,7 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch
 4.  Only infinitive verbs, adjectives and nouns.
 5.  No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette").
 6.  No numeral adjectives.
-7.  No words in the plural (except invariable words like "univers", or same spelling than singular like "heureux").
+7.  No words in the plural (except invariable words like "univers", or same spelling as singular like "heureux").
 8.  No female adjectives (except words with same spelling for male and female adjectives like "magique").
 9.  No words with several senses AND different spelling in speaking like "verre-vert", unless a word has a meaning much more popular than another like "perle" and "pairle".
 10. No very similar words with only 1 letter of difference.

bip-0042.mediawiki

@@ -13,7 +13,7 @@
 
 ==Abstract==
 
-Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years.
+Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillennium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years.
 
 This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default.
 

bip-0048.mediawiki

@@ -99,18 +99,21 @@ Hardened derivation is used at this level.
 
 ===Script===
 
-This level splits the key space into two separate <code>script_type</code>(s). To provide
+This level splits the key space into three separate <code>script_type</code>(s). To provide
 forward compatibility for future script types this specification can be easily extended.
 
-Currently the only script types covered by this BIP are Native Segwit (p2wsh) and
-Nested Segwit (p2sh-p2wsh).
+Currently the only script types covered by this BIP are Native Segwit (p2wsh),
+Nested Segwit (p2sh-p2wsh), and Taproot (p2tr).
 
 The following path represents Nested Segwit (p2sh-p2wsh) mainnet, account 0:
 <code>1'</code>: Nested Segwit (p2sh-p2wsh) <code>m/48'/0'/0'/1'</code></br>
 
 The following path represents Native Segwit (p2wsh) mainnet, account 0:
 <code>2'</code>: Native Segwit (p2wsh) <code>m/48'/0'/0'/2'</code></br>
 
+The following path represents Taproot (p2tr) mainnet, account 0:
+<code>3'</code>: Taproot (p2tr) <code>m/48'/0'/0'/3'</code></br>
+
 The recommended default for wallets is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
 
 To add new script types submit a PR to this specification and include it in the list above:
@@ -145,6 +148,13 @@ Public derivation is used at this level.
 |-
 |mainnet
 |first
+|p2sh-p2wsh
+|external
+|first
+|m / 48' / 0' / 0' / 1' / 0 / 0
+|-
+|mainnet
+|first
 |p2wsh
 |external
 |first
@@ -185,6 +195,13 @@ Public derivation is used at this level.
 |second
 |m / 48' / 0' / 1' / 2' / 0 / 1
 |-
+|mainnet
+|first
+|p2tr
+|external
+|first
+|m / 48' / 0' / 0' / 3' / 0 / 0
+|-
 |testnet
 |first
 |p2sh-p2wsh
@@ -240,6 +257,13 @@ Public derivation is used at this level.
 |change
 |second
 |m / 48' / 1' / 1' / 2' / 1 / 1
+|-
+|testnet
+|first
+|p2tr
+|external
+|first
+|m / 48' / 1' / 0' / 3' / 0 / 0
 |}
 
 

bip-0052.mediawiki

@@ -118,7 +118,7 @@ The HeavyHash is performed in three stages:
 
 # Keccak hash
 # Matrix-vector multiplication
-# Keccak of the result xorred with the hashed input
+# Keccak of the result xored with the hashed input
 
 Note that the most efficient matrix-vector multiplication is performed on a
 photonic miner. However, this linear algebra operation can be performed on any