Implement BIP 123 for BIP 90 (merging master)

luke-jr · luke-jr · commit fd5a85d6b8b6 · 2016-12-15T04:10:07.000Z
diff --git a/README.mediawiki b/README.mediawiki
@@ -344,6 +344,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0090.mediawiki|90]]
+| Buried Deployments
+| Suhas Daftuar
+| Informational
+| Draft
+|-
 | [[bip-0099.mediawiki|99]]
 | Motivation and deployment of consensus rule changes ([soft/hard]forks)
 | Jorge Timón
@@ -385,12 +391,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Washington Y. Sanchez
 | Standard
 | Draft
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0109.mediawiki|109]]
 | Two million byte size limit with sigop and sighash limits
 | Gavin Andresen
 | Standard
-| Draft
+| Rejected
 |- style="background-color: #ffffcf"
 | [[bip-0111.mediawiki|111]]
 | NODE_BLOOM service bit
diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki
@@ -12,6 +12,10 @@
 
 This BIP describes a new opcode (OP_CHECKHASHVERIFY) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them.
 
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
 ==Motivation==
 
 The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.
diff --git a/bip-0018.mediawiki b/bip-0018.mediawiki
@@ -12,6 +12,10 @@
 
 This BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck.
 
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
 ==Motivation==
 
 The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.
diff --git a/bip-0019.mediawiki b/bip-0019.mediawiki
@@ -12,6 +12,10 @@
 
 This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications.
 
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
 ==Motivation==
 
 Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature.
diff --git a/bip-0020.mediawiki b/bip-0020.mediawiki
@@ -13,6 +13,9 @@ BIP 0020 is based off an earlier document by Nils Schneider. '''And has been rep
 ==Abstract==
 This BIP proposes a URI scheme for making Bitcoin payments.
 
+==Copyright==
+This BIP is licensed under the BSD 2-clause license.
+
 ==Motivation==
 The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.
 
diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki
@@ -13,6 +13,10 @@
 This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
 Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.
 
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
 ==Specification==
 
 ===Block Template Request===
diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki
@@ -12,6 +12,10 @@
 
 This BIP describes extensions to the getblocktemplate JSON-RPC call to enhance pooled mining.
 
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
 ==Specification==
 
 Note that all sections of this specification are optional extensions on top of [[bip-0022.mediawiki|BIP 22]].
diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki
@@ -127,3 +127,8 @@ The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributi
 
 == References ==
 <references>
+
+
+== Copyright ==
+This document is placed in the public domain.
+
diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki
@@ -0,0 +1,97 @@
+<pre>
+  BIP: 90
+  Layer: Consensus (hard fork)
+  Title: Buried Deployments
+  Author: Suhas Daftuar <sdaftuar@chaincode.com>
+  Status: Draft
+  Type: Informational
+  Created: 2016-11-08
+</pre>
+
+
+==Abstract==
+
+Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers.  Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced.
+
+==Motivation==
+
+BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers.  In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block version (N) in use on the network, and those rules became enforced under the following conditions:
+# 75% rule: If 750 of the prior 1000 blocks are version N+1 or higher, then blocks with version N+1 or higher must correctly enforce the new consensus rule.
+# 95% rule: If 950 of the prior 1000 blocks are version N+1 or higher, then blocks with version less than N+1 are invalid.
+
+Please see those [[#References|BIPs]] for more details.
+
+Note that this trigger mechanism is dependent on the chain history.  To validate a block, we must test whether the trigger was met by looking at the previous 1000 blocks in the chain before it, which can be inefficient.
+
+In addition, this mechanism for code deployments have been deprecated in favor of BIP 9 deployments, which offer several advantages (please see [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP 9]).
+
+Thus we propose elimination of the logic implementing these kinds of deployments, by replacing the test which governs enforcement of BIP 34, BIP 65, and BIP 66 with simple height checks, which we choose to be the block height triggering the 95% activation rule on mainnet for each of those deployments.  This simplification of the consensus rules would reduce the technical debt associated with deployment of those consensus changes.
+
+==Considerations==
+
+It is technically possible for this to be a non-backwards compatible change.  For example, if an alternate chain were created in which BIP 34's 95% activation triggered at a lower height (H') than it did on the current mainnet chain (H), then older software would enforce that version 1 blocks were invalid at heights between H' and H, while newer software implementing this change would not.  Similarly, this BIP proposes doing away with the 75% threshold check altogether, which means, for example, that a version 2 block forking off of mainnet at height H-1 which omitted the height in coinbase would be invalid to older software, while accepted by newer software.
+
+However, while newer software and older software might validate old blocks differently, that could only cause a consensus split if there were an extremely large blockchain reorganization onto a chain built off such a block.  As of November 2016, the most recent of these changes (BIP 65, enforced since December 2015) has nearly 50,000 blocks built on top of it.  The occurrence of such a reorg that would cause the activating block to be disconnected would raise fundamental concerns about the security assumptions of Bitcoin, a far bigger issue than any non-backwards compatible change.
+
+So while this proposal could <i>theoretically</i> result in a consensus split, it is extremely unlikely, and in particular any such circumstances would be sufficiently damaging to the Bitcoin network to dwarf any concerns about the effects of this proposed change.
+
+==Specification==
+
+The BIP 34, 66, and 65 activation heights are set to 227931, 363725, and 388381, respectively.
+
+The 1000-block lookback test, first described in BIP 34, is no longer performed during validation of any blocks.  Instead, a new check is added:
+
+    if((block.nVersion < 2 && nHeight >= consensusParams.BIP34Height) ||
+       (block.nVersion < 3 && nHeight >= consensusParams.BIP66Height) ||
+       (block.nVersion < 4 && nHeight >= consensusParams.BIP65Height))
+            return state.Invalid(false, REJECT_OBSOLETE, strprintf("bad-version(0x%08x)", block.nVersion),
+                                 strprintf("rejected nVersion=0x%08x block", block.nVersion));
+
+Furthermore, rather than consider the block versions of the prior 1000 blocks to determine whether to enforce BIP 34, BIP 65, or BIP 66 on a given block, we instead just compare the height of the block being validated with the stored activation heights:
+
+    // Enforce rule that the coinbase starts with serialized block height
+    if (nHeight >= consensusParams.BIP34Height)
+    {
+        CScript expect = CScript() << nHeight;
+        if (block.vtx[0].vin[0].scriptSig.size() < expect.size() ||
+            !std::equal(expect.begin(), expect.end(), block.vtx[0].vin[0].scriptSig.begin())) {
+            return state.DoS(100, false, REJECT_INVALID, "bad-cb-height", false, "block height mismatch in coinbase");
+        }
+    }
+
+and
+
+    // Start enforcing the DERSIG (BIP66) rule
+    if (pindex->nHeight >= chainparams.GetConsensus().BIP66Height) {
+        flags |= SCRIPT_VERIFY_DERSIG;
+    }
+
+    // Start enforcing CHECKLOCKTIMEVERIFY (BIP65) rule
+    if (pindex->nHeight >= chainparams.GetConsensus().BIP65Height) {
+        flags |= SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY;
+    }
+
+Please see the implementation for additional details.
+
+==Implementation==
+
+https://github.com/bitcoin/bitcoin/pull/8391.
+
+
+==References==
+
+[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase] 
+
+[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 Strict DER signatures]
+
+[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65 OP_CHECKLOCKTIMEVERIFY]
+
+[https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9 Version bits with timeout and delay]
+
+==Acknowledgements==
+
+Thanks to Nicolas Dorier for drafting an initial version of this BIP, and to Alex Morcos, Matt Corallo, and Greg Maxwell for suggestions and feedback.
+
+==Copyright==
+
+This document is placed in the public domain.
diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki
@@ -3,7 +3,7 @@
   Layer: Consensus (hard fork)
   Title: Two million byte size limit with sigop and sighash limits
   Author: Gavin Andresen <gavinandresen@gmail.com>
-  Status: Draft
+  Status: Rejected
   Type: Standards Track
   Created: 2016-01-28
 </pre>
diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
@@ -121,18 +121,18 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 # MSG_CMPCT_BLOCK inv objects MUST NOT appear anywhere except for in getdata messages.
 
 ====cmpctblock====
-# The cmpctblock message is defined as as a message containing a serialized HeaderAndShortIDs message and pchCommand == "cmpctblock".
+# The cmpctblock message is defined as a message containing a serialized HeaderAndShortIDs message and pchCommand == "cmpctblock".
 # Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the short transaction ID for each unconfirmed transaction they have available (ie in their mempool) and compare each to each short transaction ID in the cmpctblock message.
 # After finding already-available transactions, nodes which do not have all transactions available to reconstruct the full block SHOULD request the missing transactions using a getblocktxn message.
 # A node MUST NOT send a cmpctblock message unless they are able to respond to a getblocktxn message which requests every transaction in the block.
 # A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing chain with a valid proof-of-work. A node MAY send a cmpctblock before validating that each transaction in the block validly spends existing UTXO set entries.
 
 ====getblocktxn====
-# The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn".
+# The getblocktxn message is defined as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn".
 # Upon receipt of a properly-formatted getblocktxn message, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with either an appropriate blocktxn message, or a full block message. A blocktxn response MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested.
 
 ====blocktxn====
-# The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn".
+# The blocktxn message is defined as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn".
 # Upon receipt of a properly-formatted requested blocktxn message, nodes SHOULD attempt to reconstruct the full block by:
 ## Taking the prefilledtxn transactions from the original cmpctblock and placing them in the marked positions.
 ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
@@ -186,6 +186,8 @@ Compact blocks version 2 is almost identical to version 1, but supports segregat
 
 # As high-bandwidth mode permits relaying of CMPCTBLOCK messages prior to full validation (requiring only that the block header is valid before relay), nodes SHOULD NOT ban a peer for announcing a new block with a CMPCTBLOCK message that is invalid, but has a valid header.  For avoidance of doubt, nodes SHOULD bump their peer-to-peer protocol version to 70015 or higher to signal that they will not ban or punish a peer for announcing compact blocks prior to full validation, and nodes SHOULD NOT announce a CMPCTBLOCK to a peer with a version number below 70015 before fully validating the block.
 
+# SPV nodes which implement this spec must consider the implications of accepting blocks which were not validated by the node which provided them. Especially SPV nodes which allow users to select a "trusted full node" to sync from may wish to avoid implementing this spec in high-bandwidth mode.
+
 ==Justification==
 
 ====Protocol design====
