From ebba30aa86452590f2d505e0ed058f0b64586258 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Mon, 1 Feb 2016 22:34:17 +0000 Subject: New BIP to revise BIP 1 --- bip-biprevised.mediawiki | 91 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 bip-biprevised.mediawiki diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki new file mode 100644 index 0000000..7b3c00b --- /dev/null +++ b/bip-biprevised.mediawiki @@ -0,0 +1,91 @@ +
+  BIP: x
+  Title: BIP Status and Comments
+  Status: Draft
+  Type: Process
+  Created: 2016-02-01
+
+ +==Abstract== + +BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. +Additionally, some BIPs have been adopted which are deemed unadvisable or unsafe by experts in the field, and there is no indication of this at present. +Finally, BIP 1 only allows a single copyright license generally considered deprecated, or publication under the public domain (which is not legally recognised in all jurisdictions). +This BIP intends to address these problems by more specifically defining the Status field, recommending a forum for people to comment on BIPs, and expanding the list of allowable BIP licenses. + +==Copyright== + +This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. + +==Specification== + +===BIP status field=== + +Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. + +A BIP may only change status from Draft (or Rejected) to Accepted, 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 Accepted 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 Accepted status if it meets the criteria required as described in the previous paragraph. + +An Accepted 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. + +A process BIP may change status from Draft to Active when it achieves consensus on the mailing list. + +====Progression to Final status==== + +See 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 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). + +Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month. + +API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications. + +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 [Bitcoin Core's doc/bips.md file](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md) as well as [Bitcoin Wallet for Android's wallet/README.specs file](https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs). + +====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. + +===BIP comments=== + +Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. + +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 . + +Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances: + +* Unanimously Recommended for implementation +* Unanimously Discourage for implementation +* Mostly Recommended for implementation, with some Discouragement +* Mostly Discouraged for implementation, with some Recommendation + +To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other. + +===BIP licensing=== + +New BIPs may be accepted with the following licenses: + +====Recommended licenses==== + +* OSI-approved BSD 1, 2, or 3 clause licenses +* Creative Commons CC0 1.0 Universal +* GNU All-Permissive License + +====Not recommented, but acceptable licenses==== + +* Apache License, version 2.0 +* Apple's Common Documentation License, version 1.0 +* Boost Software License, version 1.0 +* Creative Commons Attribution 4.0 International +* Creative Commons Attribution-ShareAlike 4.0 International +* Expat/MIT/X11 license +* GNU Affero General Public License (AGPL), version 3 +* GNU Free Documentation License +* GNU General Public License (GPL), version 2 or 3 +* GNU Lesser General Public License (LGPL), version 2.1 or 3 +* Open Publication License, version 1.0 -- cgit v1.2.3 From 6e34af58f9923f1af64c7a0b3d1920ad0ef69d25 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Mon, 1 Feb 2016 23:18:33 +0000 Subject: bip-biprevised: See Also links --- bip-biprevised.mediawiki | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki index 7b3c00b..39853af 100644 --- a/bip-biprevised.mediawiki +++ b/bip-biprevised.mediawiki @@ -35,7 +35,7 @@ A process BIP may change status from Draft to Active when it achieves consensus ====Progression to Final status==== -See BIP 123 for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123. +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. @@ -89,3 +89,8 @@ New BIPs may be accepted with the following licenses: * GNU General Public License (GPL), version 2 or 3 * GNU Lesser General Public License (LGPL), version 2.1 or 3 * Open Publication License, version 1.0 + +==See Also== + +* [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]] +* [[bip-0123.mediawiki|BIP 123: BIP Classification]] -- cgit v1.2.3 From c61f4d83009fa11bc72203e0ecdface08f4626f2 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Mon, 1 Feb 2016 23:20:58 +0000 Subject: Bugfix: bip-biprevised: MediaWiki linking --- bip-biprevised.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki index 39853af..efbfa78 100644 --- a/bip-biprevised.mediawiki +++ b/bip-biprevised.mediawiki @@ -45,7 +45,7 @@ Peer services BIPs should be observed to be adopted by at least 1% of public lis API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications. -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 [Bitcoin Core's doc/bips.md file](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md) as well as [Bitcoin Wallet for Android's wallet/README.specs file](https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs). +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==== -- cgit v1.2.3 From cfbde44a3c7020ee26be39205ab685c383a3b4d1 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Mon, 1 Feb 2016 23:29:07 +0000 Subject: bip-biprevised: Link licenses, and remove obsolete Apple licence and non-existent OSI-approved 1-clause BSD license --- bip-biprevised.mediawiki | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki index efbfa78..0774962 100644 --- a/bip-biprevised.mediawiki +++ b/bip-biprevised.mediawiki @@ -72,23 +72,23 @@ New BIPs may be accepted with the following licenses: ====Recommended licenses==== -* OSI-approved BSD 1, 2, or 3 clause licenses -* Creative Commons CC0 1.0 Universal -* GNU All-Permissive License +* [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license] +* [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license] +* [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal] +* [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License] ====Not recommented, but acceptable licenses==== -* Apache License, version 2.0 -* Apple's Common Documentation License, version 1.0 -* Boost Software License, version 1.0 -* Creative Commons Attribution 4.0 International -* Creative Commons Attribution-ShareAlike 4.0 International -* Expat/MIT/X11 license -* GNU Affero General Public License (AGPL), version 3 -* GNU Free Documentation License -* GNU General Public License (GPL), version 2 or 3 -* GNU Lesser General Public License (LGPL), version 2.1 or 3 -* Open Publication License, version 1.0 +* [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0] +* [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0] +* [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International] +* [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International] +* [https://opensource.org/licenses/MIT Expat/MIT/X11 license] +* [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer] +* [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License] +* [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer] +* [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer] +* [http://opencontent.org/openpub/ Open Publication License, version 1.0] ==See Also== -- cgit v1.2.3 From 97655c211a7454b4bcc01acefd4b88f979e7853f Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Mon, 1 Feb 2016 23:49:37 +0000 Subject: bip-biprevised: Clarify licensing of literal code inclusion in BIPs --- bip-biprevised.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki index 0774962..18ec1dd 100644 --- a/bip-biprevised.mediawiki +++ b/bip-biprevised.mediawiki @@ -77,6 +77,8 @@ New BIPs may be accepted with the following licenses: * [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal] * [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License] +In addition, it is recommended that literal code included in the BIP be available under the same license terms as the project it modifies, when that license is acceptable within a BIP. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms (listed below, as not recommended but acceptable) as well as one of the above with the rest of the BIP text. + ====Not recommented, but acceptable licenses==== * [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0] -- cgit v1.2.3 From fe0870ed0630f663c6d2df8626780b5800241a56 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Tue, 2 Feb 2016 00:37:08 +0000 Subject: bip-biprevised: Add Rationales and clarify literal code licensing --- bip-biprevised.mediawiki | 43 ++++++++++++++++++++++++++++++++++++++----- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki index 18ec1dd..93af1b8 100644 --- a/bip-biprevised.mediawiki +++ b/bip-biprevised.mediawiki @@ -17,9 +17,9 @@ This BIP intends to address these problems by more specifically defining the Sta This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. -==Specification== +==BIP status field== -===BIP status field=== +===Specification=== Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. @@ -51,7 +51,24 @@ Software authors are encouraged to publish summaries of what BIPs their software 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. -===BIP comments=== +===Rationale=== + +Why can the economic consensus 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. + +What is the ideal percentage of listening nodes needed to adopt peer services proposals? + +* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront. + +Should two software projects need to release an implementation of API/RPC and application layer BIPs? + +* With only one implementation of these, there is no other program for which a standard interface is used with or needed. +* Even if there are only two projects, some standard coordination between them exists. + +==BIP comments== + +===Specification=== Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. @@ -66,10 +83,19 @@ Summary tones may be chosen from the following, but this BIP does not intend to To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other. -===BIP licensing=== +===Rationale=== + +Will BIP comments be censored or limited to particular participants/"experts"? + +* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public. +* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed. + +==BIP licensing== New BIPs may be accepted with the following licenses: +===Specification=== + ====Recommended licenses==== * [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license] @@ -77,7 +103,7 @@ New BIPs may be accepted with the following licenses: * [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal] * [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License] -In addition, it is recommended that literal code included in the BIP be available under the same license terms as the project it modifies, when that license is acceptable within a BIP. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms (listed below, as not recommended but acceptable) as well as one of the above with the rest of the BIP text. +In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text. ====Not recommented, but acceptable licenses==== @@ -92,6 +118,13 @@ In addition, it is recommended that literal code included in the BIP be availabl * [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer] * [http://opencontent.org/openpub/ Open Publication License, version 1.0] +===Rationale=== + +Why are there software licenses included? + +* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP. +* Despite this, not all software licenses would be acceptable for content included in BIPs. + ==See Also== * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]] -- cgit v1.2.3 From 81741909838adc2e2c0f4d7f3c66f54a01e6e010 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Tue, 2 Feb 2016 04:14:26 +0000 Subject: bip-biprevised: Add Rationale for defining of the economy --- bip-biprevised.mediawiki | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki index 93af1b8..a4746de 100644 --- a/bip-biprevised.mediawiki +++ b/bip-biprevised.mediawiki @@ -53,6 +53,17 @@ A proposal is said to have achieved consensus if it has been open to discussion ===Rationale=== +How is the entire Bitcoin economy defined by people selling goods/services and holders? + +* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price. + +Why aren't included in the economy? + +* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as ) be involved in the economy. +* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules. +* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges. +* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not. + Why can the economic consensus 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. -- cgit v1.2.3 From 9906db4b7a1ee58f688431f02af500de3ac351df Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Tue, 2 Feb 2016 06:10:52 +0000 Subject: bip-biprevised: Add Rationale explaining how-it-is --- bip-biprevised.mediawiki | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki index a4746de..29de31a 100644 --- a/bip-biprevised.mediawiki +++ b/bip-biprevised.mediawiki @@ -64,6 +64,10 @@ Why aren't included in the economy? * Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges. * Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not. +But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision? + +* 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? * 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. -- cgit v1.2.3 From ae7cc37fe00e17e433a3b2d536737be5439c7ac0 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Tue, 2 Feb 2016 07:51:09 +0000 Subject: bip-biprevised: Address comments by Dave Scotese and Ryan Grant --- bip-biprevised.mediawiki | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki index 29de31a..b9efbc6 100644 --- a/bip-biprevised.mediawiki +++ b/bip-biprevised.mediawiki @@ -49,7 +49,7 @@ Software authors are encouraged to publish summaries of what BIPs their software ====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. +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. ===Rationale=== @@ -76,26 +76,35 @@ What is the ideal percentage of listening nodes needed to adopt peer services pr * This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront. -Should two software projects need to release an implementation of API/RPC and application layer BIPs? +Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final? -* With only one implementation of these, there is no other program for which a standard interface is used with or needed. -* Even if there are only two projects, some standard coordination between them exists. +* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed. +* Even if there are only two projects rather than more, some standard coordination between them exists. + +What if a BIP is proposed that only makes sense for a single specific project? + +* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place. ==BIP comments== ===Specification=== -Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. +Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. If a BIP is not yet completed, reviewers should plan to review the new version and remove or revise their comments as applicable, updating the timestamp in the review. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month). 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 . Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances: +* No comments yet. * Unanimously Recommended for implementation * Unanimously Discourage for implementation * Mostly Recommended for implementation, with some Discouragement * Mostly Discouraged for implementation, with some Recommendation +For example, the preamble to BIP 1 would be updated to include the (markup) line: + + Comments: [https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 No comments yet.] + To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other. ===Rationale=== -- cgit v1.2.3 From ddd34bf496f2cbd1fad7e2ac14c080ffa1b88e0a Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Tue, 2 Feb 2016 07:54:03 +0000 Subject: Bugfix: bip-biprevised: Preamble cannot use links due to 

---
 bip-biprevised.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index b9efbc6..7c75995 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -103,7 +103,8 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 
 For example, the preamble to BIP 1 would be updated to include the (markup) line:
 
-    Comments: [https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 No comments yet.]
+    Comments-Summary: No comments yet.
+    Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 
-- 
cgit v1.2.3


From c79db0a9eced8e6baa76a7f16153572e5749321b Mon Sep 17 00:00:00 2001
From: emeth- 
Date: Tue, 2 Feb 2016 06:19:47 -0600
Subject: fix typo

---
 bip-biprevised.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 7c75995..094d156 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -130,7 +130,7 @@ New BIPs may be accepted with the following licenses:
 
 In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 
-====Not recommented, but acceptable licenses====
+====Not recommended, but acceptable licenses====
 
 * [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
 * [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
-- 
cgit v1.2.3


From 56eb7958bd380010117a68bb438c5683026ee6a5 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 19:03:28 +0000
Subject: bip-biprevised: Clarify informational nature of Final status change
 criteria

---
 bip-biprevised.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 7c75995..174c9f9 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -47,6 +47,8 @@ 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].
 
+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.
+
 ====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.
-- 
cgit v1.2.3


From c5f9a101111276b5e27cbe2bca1cd4942ebca508 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 19:07:14 +0000
Subject: bip-biprevised: Allow for a second forum for BIP comments

---
 bip-biprevised.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 174c9f9..4e30f24 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -95,6 +95,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.
-- 
cgit v1.2.3


From 37ef0f9f79295ae8f1cb1a5c7950e59c1302fef9 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 3 Feb 2016 19:20:12 +0000
Subject: bip-biprevised: Avoid "consensus" outside of "consensus rules", and
 move formal definition thereof to the only location it matters (Process BIPs
 becoming Active)

---
 bip-biprevised.mediawiki | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 4e30f24..a7de3a1 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.
 
@@ -49,10 +49,6 @@ Software authors are encouraged to publish summaries of what BIPs their software
 
 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.
 
-====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.
-
 ===Rationale===
 
 How is the entire Bitcoin economy defined by people selling goods/services and holders?
@@ -70,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?
 
@@ -158,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]
-- 
cgit v1.2.3


From 04fce4aa75f6c69b57850070c2e837cd7671f233 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Thu, 4 Feb 2016 04:10:30 +0000
Subject: bip-biprevised: Clarify soft-fork blocking by ec. consensus

---
 bip-biprevised.mediawiki | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index a7de3a1..b496149 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -37,7 +37,7 @@ A process BIP may change status from Draft to Active when it achieves rough cons
 
 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 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 soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their 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 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).
 
@@ -70,6 +70,10 @@ 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 economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
 
+What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?
+
+* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.
+
 What is the ideal percentage of listening nodes needed to adopt peer services proposals?
 
 * This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
-- 
cgit v1.2.3


From a2e87c208f45072f266f9d5788664209aaeccfcc Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Thu, 4 Feb 2016 04:12:03 +0000
Subject: Assign BIP 2: BIP Status and Comments

---
 README.mediawiki         |   6 ++
 bip-0002.mediawiki       | 162 +++++++++++++++++++++++++++++++++++++++++++++++
 bip-biprevised.mediawiki | 161 ----------------------------------------------
 3 files changed, 168 insertions(+), 161 deletions(-)
 create mode 100644 bip-0002.mediawiki
 delete mode 100644 bip-biprevised.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index eda7fbf..389d21e 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -19,6 +19,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Process
 | Active
 |-
+| [[bip-0002.mediawiki|2]]
+| BIP Status and Comments
+| Luke Dashjr
+| Process
+| Draft
+|-
 | [[bip-0009.mediawiki|9]]
 | Version bits with timeout and delay
 | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
new file mode 100644
index 0000000..ee3ae3a
--- /dev/null
+++ b/bip-0002.mediawiki
@@ -0,0 +1,162 @@
+
+  BIP: 2
+  Title: BIP Status and Comments
+  Author: Luke Dashjr 
+  Status: Draft
+  Type: Process
+  Created: 2016-02-03
+

+
+==Abstract==
+
+BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion.
+Additionally, some BIPs have been adopted which are deemed unadvisable or unsafe by experts in the field, and there is no indication of this at present.
+Finally, BIP 1 only allows a single copyright license generally considered deprecated, or publication under the public domain (which is not legally recognised in all jurisdictions).
+This BIP intends to address these problems by more specifically defining the Status field, recommending a forum for people to comment on BIPs, and expanding the list of allowable BIP licenses.
+
+==Copyright==
+
+This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
+
+==BIP status field==
+
+===Specification===
+
+Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
+
+A BIP may only change status from Draft (or Rejected) to Accepted, 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 Accepted 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 Accepted status if it meets the criteria required as described in the previous paragraph.
+
+An Accepted 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.
+
+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). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their 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 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.
+
+API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
+
+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].
+
+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===
+
+How is the entire Bitcoin economy defined by people selling goods/services and holders?
+
+* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
+
+Why aren't  included in the economy?
+
+* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as ) be involved in the economy.
+* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules.
+* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.
+* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.
+
+But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
+
+* 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*.
+
+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 economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
+
+What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?
+
+* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.
+
+What is the ideal percentage of listening nodes needed to adopt peer services proposals?
+
+* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
+
+Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final?
+
+* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.
+* Even if there are only two projects rather than more, some standard coordination between them exists.
+
+What if a BIP is proposed that only makes sense for a single specific project?
+
+* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place.
+
+==BIP comments==
+
+===Specification===
+
+Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. If a BIP is not yet completed, reviewers should plan to review the new version and remove or revise their comments as applicable, updating the timestamp in the review. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
+
+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.
+* Unanimously Recommended for implementation
+* Unanimously Discourage for implementation
+* Mostly Recommended for implementation, with some Discouragement
+* Mostly Discouraged for implementation, with some Recommendation
+
+For example, the preamble to BIP 1 would be updated to include the (markup) line:
+
+    Comments-Summary: No comments yet.
+    Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
+
+To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
+
+===Rationale===
+
+Will BIP comments be censored or limited to particular participants/"experts"?
+
+* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
+* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed.
+
+==BIP licensing==
+
+New BIPs may be accepted with the following licenses:
+
+===Specification===
+
+====Recommended licenses====
+
+* [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
+* [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
+* [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
+* [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
+
+In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
+
+====Not recommented, but acceptable licenses====
+
+* [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
+* [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
+* [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
+* [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
+* [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
+* [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
+* [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License]
+* [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
+* [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
+* [http://opencontent.org/openpub/ Open Publication License, version 1.0]
+
+===Rationale===
+
+Why are there software licenses included?
+
+* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
+* Despite this, not all software licenses would be acceptable for content included in BIPs.
+
+==See Also==
+
+* [[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]
diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
deleted file mode 100644
index b496149..0000000
--- a/bip-biprevised.mediawiki
+++ /dev/null
@@ -1,161 +0,0 @@
-
-  BIP: x
-  Title: BIP Status and Comments
-  Status: Draft
-  Type: Process
-  Created: 2016-02-01
-

-
-==Abstract==
-
-BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion.
-Additionally, some BIPs have been adopted which are deemed unadvisable or unsafe by experts in the field, and there is no indication of this at present.
-Finally, BIP 1 only allows a single copyright license generally considered deprecated, or publication under the public domain (which is not legally recognised in all jurisdictions).
-This BIP intends to address these problems by more specifically defining the Status field, recommending a forum for people to comment on BIPs, and expanding the list of allowable BIP licenses.
-
-==Copyright==
-
-This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
-
-==BIP status field==
-
-===Specification===
-
-Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
-
-A BIP may only change status from Draft (or Rejected) to Accepted, 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 Accepted 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 Accepted status if it meets the criteria required as described in the previous paragraph.
-
-An Accepted 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.
-
-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). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their 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 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.
-
-API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
-
-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].
-
-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===
-
-How is the entire Bitcoin economy defined by people selling goods/services and holders?
-
-* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
-
-Why aren't  included in the economy?
-
-* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as ) be involved in the economy.
-* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules.
-* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.
-* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.
-
-But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
-
-* 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*.
-
-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 economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
-
-What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?
-
-* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.
-
-What is the ideal percentage of listening nodes needed to adopt peer services proposals?
-
-* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
-
-Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final?
-
-* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.
-* Even if there are only two projects rather than more, some standard coordination between them exists.
-
-What if a BIP is proposed that only makes sense for a single specific project?
-
-* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place.
-
-==BIP comments==
-
-===Specification===
-
-Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. If a BIP is not yet completed, reviewers should plan to review the new version and remove or revise their comments as applicable, updating the timestamp in the review. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
-
-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.
-* Unanimously Recommended for implementation
-* Unanimously Discourage for implementation
-* Mostly Recommended for implementation, with some Discouragement
-* Mostly Discouraged for implementation, with some Recommendation
-
-For example, the preamble to BIP 1 would be updated to include the (markup) line:
-
-    Comments-Summary: No comments yet.
-    Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
-
-To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
-
-===Rationale===
-
-Will BIP comments be censored or limited to particular participants/"experts"?
-
-* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
-* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed.
-
-==BIP licensing==
-
-New BIPs may be accepted with the following licenses:
-
-===Specification===
-
-====Recommended licenses====
-
-* [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
-* [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
-* [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
-* [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
-
-In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
-
-====Not recommented, but acceptable licenses====
-
-* [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
-* [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
-* [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
-* [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
-* [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
-* [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
-* [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License]
-* [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
-* [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
-* [http://opencontent.org/openpub/ Open Publication License, version 1.0]
-
-===Rationale===
-
-Why are there software licenses included?
-
-* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
-* Despite this, not all software licenses would be acceptable for content included in BIPs.
-
-==See Also==
-
-* [[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]
-- 
cgit v1.2.3


From d21c27b96efc0072d4884fb321b3b171c340c4ac Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 00:04:55 +0000
Subject: bip-0002: Clarify that BIP comments are intended for final reviews,
 not suggestions to drafts

---
 bip-0002.mediawiki | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index bf0a768..6690bc2 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -92,7 +92,12 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 ===Specification===
 
-Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. If a BIP is not yet completed, reviewers should plan to review the new version and remove or revise their comments as applicable, updating the timestamp in the review. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
+Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
+Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
+The comments page should generally only be used to post final comments for a completed BIP.
+If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
+
+Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still cross-post their review on the comments page, provided they plan to review any new versions and remove or revise their comments as applicable. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
 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 .
 
-- 
cgit v1.2.3


From 8c50a8012ea4fcabf35f06683d7859c0bcef8e6c Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 00:18:02 +0000
Subject: bip-0002: Rewrite Abstract, and move rationale previously included in
 it to the applicable Rationale sections

---
 bip-0002.mediawiki | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 6690bc2..4d3bab0 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -9,10 +9,7 @@
 
 ==Abstract==
 
-BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion.
-Additionally, some BIPs have been adopted which are deemed unadvisable or unsafe by experts in the field, and there is no indication of this at present.
-Finally, BIP 1 only allows a single copyright license generally considered deprecated, or publication under the public domain (which is not legally recognised in all jurisdictions).
-This BIP intends to address these problems by more specifically defining the Status field, recommending a forum for people to comment on BIPs, and expanding the list of allowable BIP licenses.
+This BIP describes objective criteria that can be used to determine when a BIP Status should be changed, to ensure it is a reliable metric documenting actual usage of the proposal. It also adds a way for final comment on completed BIPs, by adding to them a reference to a wiki page and summary of the tone thereof. Finally, it extends the list of allowable BIP licenses to include many more popular options.
 
 ==Copyright==
 
@@ -52,6 +49,10 @@ These criteria are considered objective ways to observe the de facto adoption of
 
 ===Rationale===
 
+Why is this necessary at all?
+
+* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Accepted status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date.
+
 How is the entire Bitcoin economy defined by people selling goods/services and holders?
 
 * For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
@@ -65,7 +66,7 @@ Why aren't  included in the economy?
 
 But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
 
-* 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*.
+* 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 force others to use it. The BIP process does not aim to be a kind of forceful "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. 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*.
 
 How can economic agreement veto a soft-fork?
 
@@ -120,6 +121,10 @@ To avoid doubt: comments and status are unrelated metrics to judge a BIP, and ne
 
 ===Rationale===
 
+What is the purpose of BIP comments?
+
+* Various BIPs have been adopted (the criteria required for "Final" Status) despite being considered generally inadvisable. Some presently regard BIPs as a "good idea" simply by virtue of them being assigned a BIP number. Due to the low barrier of entry for submission of new BIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion.
+
 Will BIP comments be censored or limited to particular participants/"experts"?
 
 * The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
@@ -155,6 +160,12 @@ In addition, it is recommended that literal code included in the BIP be dual-lic
 
 ===Rationale===
 
+BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?
+
+* The OPL is generally regarded as obsolete, and not a license suitable for new publications.
+* Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms.
+* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
+
 Why are there software licenses included?
 
 * Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
-- 
cgit v1.2.3


From 438bb6bbab2822b1a093957b006f9f109b8a13e0 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 00:22:05 +0000
Subject: bip-0002: Be more specific on how additional comments forums can be
 specified

---
 bip-0002.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 4d3bab0..2558f20 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -102,7 +102,7 @@ Some BIPs receive exposure outside the development community prior to completion
 
 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.
+In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may choose to list a second forum for BIP comments, in addition to the Bitcoin Wiki. In this case, the second forum's URI should be listed below the Bitcoin Wiki's URI.
 
 Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
 
@@ -112,10 +112,11 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 * Mostly Recommended for implementation, with some Discouragement
 * Mostly Discouraged for implementation, with some Recommendation
 
-For example, the preamble to BIP 1 would be updated to include the (markup) line:
+For example, the preamble to BIP 1 might be updated to include the line:
 
     Comments-Summary: No comments yet.
     Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
+                  https://some-other-wiki.org/BIP_1_Comments
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 
-- 
cgit v1.2.3


From fc352d54e825c04527d5573bed90fb8a3463fe2f Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 01:06:08 +0000
Subject: bip-0002: Be more explicit on the need for review to primarily occur
 on the ML during drafting

---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 2558f20..571361c 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -98,7 +98,7 @@ Reviewers of the BIP who consider themselves qualified, should post their own co
 The comments page should generally only be used to post final comments for a completed BIP.
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
-Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still cross-post their review on the comments page, provided they plan to review any new versions and remove or revise their comments as applicable. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
+Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
 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 .
 
-- 
cgit v1.2.3


From 54a753d6c913077acd5621989fa51c04b88ea4ad Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 01:08:39 +0000
Subject: bip-0002: Note that the comments must address the proposal itself

---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 571361c..e5e50ba 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -95,7 +95,7 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
-The comments page should generally only be used to post final comments for a completed BIP.
+The comments page should generally only be used to post final comments for a completed BIP, and must address the proposal itself (explicitly *not* including the merits of the author(s) nor discussions/processes involved in the drafting of it).
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
 Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
-- 
cgit v1.2.3


From 32231cddc6db33f2557a0bd0e6a143b90c99203f Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 01:32:59 +0000
Subject: Revert "bip-0002: Note that the comments must address the proposal
 itself"

This reverts commit 54a753d6c913077acd5621989fa51c04b88ea4ad.
---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index e5e50ba..571361c 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -95,7 +95,7 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
-The comments page should generally only be used to post final comments for a completed BIP, and must address the proposal itself (explicitly *not* including the merits of the author(s) nor discussions/processes involved in the drafting of it).
+The comments page should generally only be used to post final comments for a completed BIP.
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
 Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
-- 
cgit v1.2.3