1 files changed, 9 insertions, 8 deletions
diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 094d156..331412a 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -31,15 +31,15 @@ An Accepted BIP may progress to Final only when specific criteria reflecting rea
 
 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.
 
-A process BIP may change status from Draft to Active when it achieves consensus on the mailing list.
+A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.
 
 ====Progression to Final status====
 
 See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
 
-A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic consensus may reject a soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
+A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic agreement to block the soft-fork with a hard-fork, may be cause to reject that soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
 
-A hard-fork BIP requires consensus from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Consensus must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish pre-Final status consensus to adopt a BIP). This consensus cannot be reached merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
+A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
 
 Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
 
@@ -47,9 +47,7 @@ API/RPC and application layer BIPs must be implemented by at least two independe
 
 Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file].
 
-====Formally defining consensus====
-
-A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion. Objections are assumed to be either substantiated or obstructive, and when giving a determination of an objection being obstructive, clear reasoning must be offered.
+These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.
 
 ===Rationale===
 
@@ -68,9 +66,9 @@ But they're doing something important and have invested a lot in Bitcoin! Should
 
 * This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to enforce it. The BIP process does not aim to be a kind of "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
 
-Why can the economic consensus veto a soft-fork?
+How can economic agreement veto a soft-fork?
 
-* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.
+* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
 
 What is the ideal percentage of listening nodes needed to adopt peer services proposals?
 
@@ -93,6 +91,8 @@ Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary ton
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 
+In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may also choose to list a second forum for BIP comments.
+
 Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
 
 * No comments yet.
@@ -154,3 +154,4 @@ Why are there software licenses included?
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]
 * [[bip-0123.mediawiki|BIP 123: BIP Classification]]
+* [https://tools.ietf.org/html/rfc7282 RBF 7282: On Consensus and Humming in the IETF]