BIP 2: Include Layer header from BIP 123 in general preamble and change list

bip-0002.mediawiki

@@ -74,6 +74,7 @@ For each new BIP that comes in an editor does the following:
 * The title should accurately describe the content.
 * The BIP draft must have been sent to the Bitcoin development mailing list for discussion.
 * Motivation and backward compatibility (when applicable) must be addressed.
+* The defined Layer header must be correctly assigned for the given specification.
 * Licensing terms must be acceptable for BIPs.
 
 If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
@@ -120,6 +121,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 
 <pre>
   BIP: <BIP number, or "?" before being assigned>
+  Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
   Title: <BIP title; maximum 44 characters>
   Author: <list of authors' real names and email addrs>
 * Discussions-To: <email address>
@@ -137,6 +139,9 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 * Superseded-By: <BIP number>
 </pre>
 
+The Layer header documents which layer of Bitcoin the BIP applies to.
+See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
+
 The Author header lists the names and email addresses of all the authors/owners of the BIP.
 The format of the Author header value must be
 
@@ -191,8 +196,6 @@ A process BIP may change status from Draft to Active when it achieves rough cons
 
 ====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 might have 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).
@@ -395,6 +398,7 @@ Why is Public Domain no longer acceptable for new BIPs?
 * An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.
 * BIP Comments are newly introduced.
 * The License preamble headers have been added.
+* The Layer header is included from BIP 123.
 * Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
 * Email addresses are now required for authors.
 * The Post-History header may be provided as a link instead of a simple date.