From 836d2dc91e1e21a77c0b0364ec4a0a9722c02a4f Mon Sep 17 00:00:00 2001 From: Suhas Daftuar Date: Tue, 8 Nov 2016 12:03:32 -0500 Subject: [PATCH 1/9] Initial draft of buried deployments. --- bip-buried-deployments.mediawiki | 96 ++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 bip-buried-deployments.mediawiki diff --git a/bip-buried-deployments.mediawiki b/bip-buried-deployments.mediawiki new file mode 100644 index 00000000..84e3f4d6 --- /dev/null +++ b/bip-buried-deployments.mediawiki @@ -0,0 +1,96 @@ +
+BIP: ?
+Title: Buried deployments
+Author: Suhas Daftuar 
+Status: Draft
+Type: Standards Track
+Created: 2016-11-08
+
+ + +==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 and optimization) 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 and simultaneously provide a performance optimization. + +==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 theoretically 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. From 395262bd1d26263b0105b5ac96782b3f3cf3bf71 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 30 Nov 2016 10:09:54 +0000 Subject: [PATCH 2/9] BIPs 17, 18, 19, 20, 22, and 23: Add missing Copyright section --- bip-0017.mediawiki | 4 ++++ bip-0018.mediawiki | 4 ++++ bip-0019.mediawiki | 4 ++++ bip-0020.mediawiki | 3 +++ bip-0022.mediawiki | 4 ++++ bip-0023.mediawiki | 4 ++++ 6 files changed, 23 insertions(+) diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki index 44011d57..38634879 100644 --- a/bip-0017.mediawiki +++ b/bip-0017.mediawiki @@ -11,6 +11,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 index fce42004..15e44187 100644 --- a/bip-0018.mediawiki +++ b/bip-0018.mediawiki @@ -11,6 +11,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 index 7784e084..228fdc83 100644 --- a/bip-0019.mediawiki +++ b/bip-0019.mediawiki @@ -11,6 +11,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 index fad634b7..ff7fdedd 100644 --- a/bip-0020.mediawiki +++ b/bip-0020.mediawiki @@ -12,6 +12,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 index 4b33e595..82a13bfc 100644 --- a/bip-0022.mediawiki +++ b/bip-0022.mediawiki @@ -12,6 +12,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 index 03909587..1c7e721b 100644 --- a/bip-0023.mediawiki +++ b/bip-0023.mediawiki @@ -11,6 +11,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]]. From 148988067a7298dcb03335b1a5be8fe4e21c2f1e Mon Sep 17 00:00:00 2001 From: Ruben de Vries Date: Wed, 30 Nov 2016 17:48:54 +0100 Subject: [PATCH 3/9] add Copyright to BIP67 --- bip-0067.mediawiki | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 13e2ed99..e266ab85 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -126,3 +126,8 @@ The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributi == References == + + +== Copyright == +This document is placed in the public domain. + From 0fc3fe20ca138821f81cf454c0f0ed50e7c94229 Mon Sep 17 00:00:00 2001 From: Suhas Daftuar Date: Wed, 30 Nov 2016 12:25:52 -0500 Subject: [PATCH 4/9] Emphasize code simplification over performance optimization --- bip-buried-deployments.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-buried-deployments.mediawiki b/bip-buried-deployments.mediawiki index 84e3f4d6..e5392049 100644 --- a/bip-buried-deployments.mediawiki +++ b/bip-buried-deployments.mediawiki @@ -3,14 +3,14 @@ BIP: ? Title: Buried deployments Author: Suhas Daftuar Status: Draft -Type: Standards Track +Type: Informational Created: 2016-11-08 ==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 and optimization) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. +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== @@ -24,7 +24,7 @@ Note that this trigger mechanism is dependent on the chain history. To validate 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 and simultaneously provide a performance optimization. +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== From 710a20ad331abcd64c01f114143fbb17dc47fae2 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 30 Nov 2016 23:33:24 +0000 Subject: [PATCH 5/9] Update BIP 109 status Draft->Rejected All proponents of BIP 109 seem to agree it is dead --- README.mediawiki | 4 ++-- bip-0109.mediawiki | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README.mediawiki b/README.mediawiki index da18d6b3..f6d05c5d 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -385,12 +385,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-0109.mediawiki b/bip-0109.mediawiki index 667ef5f5..bd37489c 100644 --- a/bip-0109.mediawiki +++ b/bip-0109.mediawiki @@ -2,7 +2,7 @@ BIP: 109 Title: Two million byte size limit with sigop and sighash limits Author: Gavin Andresen - Status: Draft + Status: Rejected Type: Standards Track Created: 2016-01-28 From 5d21c93a681180b99da6b78e462f8fab245989ca Mon Sep 17 00:00:00 2001 From: Suhas Daftuar Date: Thu, 1 Dec 2016 08:56:40 -0500 Subject: [PATCH 6/9] Assign BIP90 and update README --- README.mediawiki | 6 ++++++ bip-buried-deployments.mediawiki => bip-0090.mediawiki | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) rename bip-buried-deployments.mediawiki => bip-0090.mediawiki (99%) diff --git a/README.mediawiki b/README.mediawiki index da18d6b3..3ac10784 100644 --- 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 diff --git a/bip-buried-deployments.mediawiki b/bip-0090.mediawiki similarity index 99% rename from bip-buried-deployments.mediawiki rename to bip-0090.mediawiki index e5392049..a8de9315 100644 --- a/bip-buried-deployments.mediawiki +++ b/bip-0090.mediawiki @@ -1,5 +1,5 @@ 
-BIP: ?
+BIP: 90
 Title: Buried deployments
 Author: Suhas Daftuar 
 Status: Draft

From 2bc2f060895ed43edd1553d74405d5ba2c0dcfae Mon Sep 17 00:00:00 2001
From: Suhas Daftuar 
Date: Thu, 1 Dec 2016 15:11:16 -0500
Subject: [PATCH 7/9] fix preamble

---
 bip-0090.mediawiki | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki
index a8de9315..342657c7 100644
--- a/bip-0090.mediawiki
+++ b/bip-0090.mediawiki
@@ -1,10 +1,10 @@
 
-BIP: 90
-Title: Buried deployments
-Author: Suhas Daftuar 
-Status: Draft
-Type: Informational
-Created: 2016-11-08
+  BIP: 90
+  Title: Buried Deployments
+  Author: Suhas Daftuar 
+  Status: Draft
+  Type: Informational
+  Created: 2016-11-08
 

 
 

From aee228746d6710013cb9f35b25ccb9c3f97950c7 Mon Sep 17 00:00:00 2001
From: Matt Corallo 
Date: Mon, 5 Dec 2016 13:55:40 -0800
Subject: [PATCH 8/9] Clarify SPV node usage.

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

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index e05cc2ac..69abf7c3 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -185,6 +185,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====

From 8102d5f5afd0567662d46e6b2646749c7051ba24 Mon Sep 17 00:00:00 2001
From: paveljanik 
Date: Thu, 8 Dec 2016 10:20:04 +0100
Subject: [PATCH 9/9] Fix typos

---
 bip-0152.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index 69abf7c3..109bbb3e 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -120,18 +120,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.