bip-340: reduce size of randomizers to 128 bit and provide argument

README.mediawiki

@@ -1,4 +1,4 @@
-People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [email protected]] mailing list. After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
+People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [email protected]] mailing list (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
 
 We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
 
@@ -392,7 +392,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Nicolas Dorier
 | Standard
 | Draft
-|- style="background-color: #ffffcf"
+|- style="background-color: #ffcfcf"
 | [[bip-0079.mediawiki|79]]
 | Applications
 | Bustapay :: a practical coinjoin protocol
@@ -434,6 +434,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Ethan Kosakovsky
 | Informational
 | Draft
+|- style="background-color: #ffffcf"
+| [[bip-0087.mediawiki|87]]
+| Applications
+| Hierarchy for Deterministic Multisig Wallets
+| Robert Spigler
+| Standard
+| Proposed
+|- style="background-color: #ffffcf"
+| [[bip-0088.mediawiki|88]]
+| Applications
+| Hierarchical Deterministic Path Templates
+| Dmitry Petukhov
+| Informational
+| Proposed
 |- style="background-color: #cfffcf"
 | [[bip-0090.mediawiki|90]]
 |
@@ -645,6 +659,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |- style="background-color: #ffffcf"
+| [[bip-0129.mediawiki|129]]
+| Applications
+| Bitcoin Secure Multisig Setup (BSMS)
+| Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen, Rodolfo Novak
+| Standard
+| Proposed
+|- style="background-color: #ffffcf"
 | [[bip-0130.mediawiki|130]]
 | Peer Services
 | sendheaders message
@@ -847,20 +868,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Greg Maxwell
 | Informational
 | Final
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0174.mediawiki|174]]
 | Applications
 | Partially Signed Bitcoin Transaction Format
 | Andrew Chow
 | Standard
-| Proposed
-|-
+| Final
+|- style="background-color: #ffcfcf"
 | [[bip-0175.mediawiki|175]]
 | Applications
 | Pay to Contract Protocol
 | Omar Shibli, Nicholas Gregory
 | Informational
-| Draft
+| Rejected
 |-
 | [[bip-0176.mediawiki|176]]
 |
@@ -953,6 +974,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0338.mediawiki|338]]
+| Peer Services
+| Disable transaction relay message
+| Suhas Daftuar
+| Standard
+| Draft
+|-
 | [[bip-0339.mediawiki|339]]
 | Peer Services
 | WTXID-based transaction relay
@@ -980,6 +1008,27 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Jonas Nick, Anthony Towns
 | Standard
 | Draft
+|- style="background-color: #ffffcf"
+| [[bip-0343.mediawiki|343]]
+| Consensus (soft fork)
+| Mandatory activation of taproot deployment
+| Shinobius, Michael Folkson
+| Standard
+| Proposed
+|-
+| [[bip-0350.mediawiki|350]]
+| Applications
+| Bech32m format for v1+ witness addresses
+| Pieter Wuille
+| Standard
+| Draft
+|-
+| [[bip-0370.mediawiki|370]]
+| Applications
+| PSBT Version 2
+| Andrew Chow
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->

bip-0002.mediawiki

@@ -192,7 +192,7 @@ A BIP may only change status from Draft (or Rejected) to Proposed, when the auth
 
 BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
 
-An Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
+A Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
 
 When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
 
@@ -326,7 +326,7 @@ For example, a preamble might include the following License header:
 
 In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement.
 
-It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
+It is also possible to license source code differently from the BIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
 
 For example, a preamble specifying the optional License-Code header might look like: