Merge branch 'master' into patch-4

Author: fametrano

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.
 
@@ -258,6 +258,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Justus Ranvier
 | Informational
 | Draft
+|- style="background-color: #ffffcf"
+| [[bip-0048.mediawiki|48]]
+| Applications
+| Multi-Script Hierarchy for Multi-Sig Wallets
+| Fontaine
+| Standard
+| Proposed
 |- style="background-color: #cfffcf"
 | [[bip-0049.mediawiki|49]]
 | Applications
@@ -392,7 +399,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 +441,27 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Ethan Kosakovsky
 | Informational
 | Draft
+|-
+| [[bip-0086.mediawiki|86]]
+| Applications
+| Key Derivation for Single Key P2TR Outputs
+| Andrew Chow
+| Standard
+| 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]]
 |
@@ -577,8 +605,8 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0118.mediawiki|118]]
 | Consensus (soft fork)
-| SIGHASH_NOINPUT
-| Christian Decker
+| SIGHASH_ANYPREVOUT for Taproot Scripts
+| Christian Decker, Anthony Towns
 | Standard
 | Draft
 |-
@@ -645,6 +673,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 +882,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 +988,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 +1022,34 @@ 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
+|-
+| [[bip-0371.mediawiki|371]]
+| Applications
+| Taproot Fields for PSBT
+| Andrew Chow
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->

bip-0002.mediawiki

@@ -41,14 +41,14 @@ It also helps to make sure the idea is applicable to the entire community and no
 Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list].
 This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal.
 Following a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request.
-This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
+This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
 
 BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
 
 It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.
 
-When the BIP draft is complete, the BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
-The BIP editor will not unreasonably reject a BIP.
+When the BIP draft is complete, a BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
+The BIP editors will not unreasonably reject a BIP.
 Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
 For a BIP to be accepted it must meet certain minimum criteria.
 It must be a clear and complete description of the proposed enhancement.
@@ -61,16 +61,19 @@ The BIP author may update the draft as necessary in the git repository. Updates
 
 It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
 
-If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
+If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editors. If the original author doesn't respond to email in a timely manner, the BIP editors will make a unilateral decision (it's not like such decisions can't be reversed :).
 
 ===BIP Editors===
 
-The current BIP editor is Luke Dashjr who can be contacted at [[mailto:[email protected]|[email protected]]].
+The current BIP editors are:
+
+* Luke Dashjr ([[mailto:[email protected]|[email protected]]])
+* Kalle Alm ([[mailto:[email protected]|[email protected]]])
 
 ===BIP Editor Responsibilities & Workflow===
 
-The BIP editor subscribes to the Bitcoin development mailing list.
-Off-list BIP-related correspondence should be sent (or CC'd) to [email protected].
+The BIP editors subscribe to the Bitcoin development mailing list.
+Off-list BIP-related correspondence should be sent (or CC'd) to the BIP editors.
 
 For each new BIP that comes in an editor does the following:
 
@@ -186,13 +189,13 @@ The typical paths of the status of BIPs are as follows:
 <img src="bip-0002/process.png"></img>
 
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
-The BIP editor may also change the status to Deferred when no progress is being made on the BIP.
+A BIP editor may also change the status to Deferred when no progress is being made on the BIP.
 
 A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
 
 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 +329,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: