Skip to content

Commit 1ba9533

Browse files
author
Matt David
committed
Merge remote-tracking branch 'upstream/master'
2 parents 9ec4be2 + acffcfb commit 1ba9533

14 files changed

+457
-208
lines changed

README.mediawiki

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -344,6 +344,12 @@ Those proposing changes should consider that ultimately consent may rest with th
344344
| Standard
345345
| Draft
346346
|-
347+
| [[bip-0090.mediawiki|90]]
348+
| Buried Deployments
349+
| Suhas Daftuar
350+
| Informational
351+
| Draft
352+
|-
347353
| [[bip-0099.mediawiki|99]]
348354
| Motivation and deployment of consensus rule changes ([soft/hard]forks)
349355
| Jorge Timón
@@ -385,12 +391,12 @@ Those proposing changes should consider that ultimately consent may rest with th
385391
| Washington Y. Sanchez
386392
| Standard
387393
| Draft
388-
|-
394+
|- style="background-color: #ffcfcf"
389395
| [[bip-0109.mediawiki|109]]
390396
| Two million byte size limit with sigop and sighash limits
391397
| Gavin Andresen
392398
| Standard
393-
| Draft
399+
| Rejected
394400
|- style="background-color: #ffffcf"
395401
| [[bip-0111.mediawiki|111]]
396402
| NODE_BLOOM service bit

bip-0002.mediawiki

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -74,6 +74,7 @@ For each new BIP that comes in an editor does the following:
7474
* The title should accurately describe the content.
7575
* The BIP draft must have been sent to the Bitcoin development mailing list for discussion.
7676
* Motivation and backward compatibility (when applicable) must be addressed.
77+
* The defined Layer header must be correctly assigned for the given specification.
7778
* Licensing terms must be acceptable for BIPs.
7879
7980
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
120121

121122
<pre>
122123
BIP: <BIP number, or "?" before being assigned>
124+
* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
123125
Title: <BIP title; maximum 44 characters>
124126
Author: <list of authors' real names and email addrs>
125127
* Discussions-To: <email address>
@@ -137,6 +139,9 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
137139
* Superseded-By: <BIP number>
138140
</pre>
139141

142+
The Layer header (only for Standards Track BIPs) documents which layer of Bitcoin the BIP applies to.
143+
See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
144+
140145
The Author header lists the names and email addresses of all the authors/owners of the BIP.
141146
The format of the Author header value must be
142147

@@ -191,8 +196,6 @@ A process BIP may change status from Draft to Active when it achieves rough cons
191196

192197
====Progression to Final status====
193198

194-
See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
195-
196199
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.
197200

198201
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?
395398
* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.
396399
* BIP Comments are newly introduced.
397400
* The License preamble headers have been added.
401+
* The Layer header is included from BIP 123.
398402
* Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
399403
* Email addresses are now required for authors.
400404
* The Post-History header may be provided as a link instead of a simple date.

bip-0017.mediawiki

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,10 @@
1111

1212
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.
1313

14+
==Copyright==
15+
16+
This BIP is licensed under the BSD 2-clause license.
17+
1418
==Motivation==
1519

1620
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.

bip-0018.mediawiki

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,10 @@
1111

1212
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.
1313

14+
==Copyright==
15+
16+
This BIP is licensed under the BSD 2-clause license.
17+
1418
==Motivation==
1519

1620
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.

bip-0019.mediawiki

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,10 @@
1111

1212
This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications.
1313

14+
==Copyright==
15+
16+
This BIP is licensed under the BSD 2-clause license.
17+
1418
==Motivation==
1519

1620
Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature.

bip-0020.mediawiki

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,9 @@ BIP 0020 is based off an earlier document by Nils Schneider. '''And has been rep
1212
==Abstract==
1313
This BIP proposes a URI scheme for making Bitcoin payments.
1414

15+
==Copyright==
16+
This BIP is licensed under the BSD 2-clause license.
17+
1518
==Motivation==
1619
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.
1720

bip-0022.mediawiki

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,10 @@
1212
This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
1313
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.
1414

15+
==Copyright==
16+
17+
This BIP is licensed under the BSD 2-clause license.
18+
1519
==Specification==
1620

1721
===Block Template Request===

bip-0023.mediawiki

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,10 @@
1111

1212
This BIP describes extensions to the getblocktemplate JSON-RPC call to enhance pooled mining.
1313

14+
==Copyright==
15+
16+
This BIP is licensed under the BSD 2-clause license.
17+
1418
==Specification==
1519

1620
Note that all sections of this specification are optional extensions on top of [[bip-0022.mediawiki|BIP 22]].

bip-0067.mediawiki

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -126,3 +126,8 @@ The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributi
126126
127127
== References ==
128128
<references>
129+
130+
131+
== Copyright ==
132+
This document is placed in the public domain.
133+

bip-0090.mediawiki

Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
<pre>
2+
BIP: 90
3+
Title: Buried Deployments
4+
Author: Suhas Daftuar <[email protected]>
5+
Status: Draft
6+
Type: Informational
7+
Created: 2016-11-08
8+
</pre>
9+
10+
11+
==Abstract==
12+
13+
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.
14+
15+
==Motivation==
16+
17+
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:
18+
# 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.
19+
# 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.
20+
21+
Please see those [[#References|BIPs]] for more details.
22+
23+
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.
24+
25+
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]).
26+
27+
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.
28+
29+
==Considerations==
30+
31+
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.
32+
33+
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.
34+
35+
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.
36+
37+
==Specification==
38+
39+
The BIP 34, 66, and 65 activation heights are set to 227931, 363725, and 388381, respectively.
40+
41+
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:
42+
43+
if((block.nVersion < 2 && nHeight >= consensusParams.BIP34Height) ||
44+
(block.nVersion < 3 && nHeight >= consensusParams.BIP66Height) ||
45+
(block.nVersion < 4 && nHeight >= consensusParams.BIP65Height))
46+
return state.Invalid(false, REJECT_OBSOLETE, strprintf("bad-version(0x%08x)", block.nVersion),
47+
strprintf("rejected nVersion=0x%08x block", block.nVersion));
48+
49+
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:
50+
51+
// Enforce rule that the coinbase starts with serialized block height
52+
if (nHeight >= consensusParams.BIP34Height)
53+
{
54+
CScript expect = CScript() << nHeight;
55+
if (block.vtx[0].vin[0].scriptSig.size() < expect.size() ||
56+
!std::equal(expect.begin(), expect.end(), block.vtx[0].vin[0].scriptSig.begin())) {
57+
return state.DoS(100, false, REJECT_INVALID, "bad-cb-height", false, "block height mismatch in coinbase");
58+
}
59+
}
60+
61+
and
62+
63+
// Start enforcing the DERSIG (BIP66) rule
64+
if (pindex->nHeight >= chainparams.GetConsensus().BIP66Height) {
65+
flags |= SCRIPT_VERIFY_DERSIG;
66+
}
67+
68+
// Start enforcing CHECKLOCKTIMEVERIFY (BIP65) rule
69+
if (pindex->nHeight >= chainparams.GetConsensus().BIP65Height) {
70+
flags |= SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY;
71+
}
72+
73+
Please see the implementation for additional details.
74+
75+
==Implementation==
76+
77+
https://github.com/bitcoin/bitcoin/pull/8391.
78+
79+
80+
==References==
81+
82+
[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase]
83+
84+
[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 Strict DER signatures]
85+
86+
[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65 OP_CHECKLOCKTIMEVERIFY]
87+
88+
[https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9 Version bits with timeout and delay]
89+
90+
==Acknowledgements==
91+
92+
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.
93+
94+
==Copyright==
95+
96+
This document is placed in the public domain.

0 commit comments

Comments
 (0)