[pull] master from bitcoin:master

README.mediawiki

@@ -28,6 +28,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Process
 | Active
 |-
+| [[bip-0003.md|3]]
+|
+| Updated BIP Process
+| Murch
+| Process
+| Draft
+|-
 | [[bip-0008.mediawiki|8]]
 |
 | Version bits with lock-in by height
@@ -497,13 +504,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Leon Olsson Curr, Pearlwort Sneed, Andrew Poelstra
 | Informational
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0094.mediawiki|94]]
 | Applications
 | Testnet 4
 | Fabian Jahr
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0098.mediawiki|98]]
 | Consensus (soft fork)
@@ -1029,13 +1036,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Jonas Nick, Tim Ruffing, Elliott Jin
 | Informational
 | Active
-|-
+|- style="background-color: #ffffcf"
 | [[bip-0328.mediawiki|328]]
 | Applications
 | Derivation Scheme for MuSig2 Aggregate Keys
 | Ava Chow
 | Informational
-| Draft
+| Proposed
 |-
 | [[bip-0329.mediawiki|329]]
 | Applications
@@ -1183,12 +1190,26 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Maxim Orlovsky
 | Standard
 | Draft
-|-
+|- style="background-color: #ffffcf"
 | [[bip-0373.mediawiki|373]]
 | Applications
 | MuSig2 PSBT Fields
 | Ava Chow
 | Standard
+| Proposed
+|-
+| [[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]]

bip-0001.mediawiki

@@ -23,7 +23,7 @@ Because the BIPs are maintained as text files in a versioned repository, their r
 There are three kinds of BIP:
 
 * A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
-* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
+* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.
 * A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
 
 ==BIP Work Flow==

bip-0002.mediawiki

@@ -183,7 +183,7 @@ BIPs may include auxiliary files such as diagrams. Auxiliary files should be inc
 There are three kinds of BIP:
 
 * A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation.
-* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
+* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.
 * A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
 
 ==BIP status field==