diff options
Diffstat (limited to 'bip-0100.mediawiki')
-rw-r--r-- | bip-0100.mediawiki | 17 |
1 files changed, 11 insertions, 6 deletions
diff --git a/bip-0100.mediawiki b/bip-0100.mediawiki index 67c2b4c..fdb62a4 100644 --- a/bip-0100.mediawiki +++ b/bip-0100.mediawiki @@ -1,5 +1,6 @@ <pre> BIP: 100 + Layer: Consensus (hard fork) Title: Dynamic maximum block size by miner vote Author: Jeff Garzik <jgarzik@gmail.com> Tom Harding <tomh@thinlink.com> @@ -8,8 +9,6 @@ Type: Standards Track Created: 2015-06-11 License: BSD-2-Clause - Comments-Summary: No comments yet. - Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100 </pre> ==Abstract== @@ -30,14 +29,14 @@ The system is compatible with emergent consensus, but whereas under that system # Initial value of <code>hardLimit</code> is 1000000 bytes, preserving current system. # Changing <code>hardLimit</code> is accomplished by encoding a proposed value, a vote, within a block's coinbase scriptSig, and by processing the votes contained in the previous retargeting period.<br /><br /> ## Vote encoding -### A vote is represented as a positive megabyte value using the BIP100 pattern<br /><br /><code>/BIP100/B[0-9]+/</code><br /><br />Example: <code>/BIP100/B8/</code> is a vote for a 8000000-byte <code>hardLimit</code>.<br /><br /> +### A vote is represented as a megabyte value using the BIP100 pattern<br /><br /><code>/BIP100/B[0-9]+/</code><br /><br />Example: <code>/BIP100/B8/</code> is a vote for a 8000000-byte <code>hardLimit</code>.<br /><br /> ### If the block height is encoded at the start of the coinbase scriptSig, as per BIP34, it is ignored. ### Only the first BIP100 pattern match is processed in "Maximum block size recalculation" below. -### A valid megabyte value is represented by consecutive base-ten digits. +### A megabyte value is represented by consecutive base-ten digits. ### If no BIP100 pattern is matched, the first matching emergent consensus pattern <code>/EB[0-9]+/</code>, if any, is accepted as the megabyte vote.<br /><br /> ## Maximum block size recalculation ### A <code>new hardLimit</code> is calculated after each difficulty adjustment period of 2016 blocks, and applies to the next 2016 blocks. -### Absent/invalid votes are counted as votes for the <code>current hardLimit</code>. +### Absent/zero-valued votes are counted as votes for the <code>current hardLimit</code>. ### The votes of the previous 2016 blocks are sorted by megabyte vote. ### Raising <code>hardLimit</code><br /><br /> #### The <code>raise value</code> is defined as the vote of the 1512th highest block, converted to bytes. @@ -50,7 +49,7 @@ The system is compatible with emergent consensus, but whereas under that system ### Otherwise, <code>new hardLimit</code> remains the same as <code>current hardLimit</code>. ===Signature Hashing Operations Limits=== -# The per-block signature hashing operations limit is scaled to (<code>hardLimit</code> rounded up to nearest megabyte)/50. +# The per-block signature hashing operations limit is scaled to (actual block size rounded up to nearest megabyte)/50. # A maximum serialized transaction size of 1000000 bytes is imposed. ===Publication of <code>hardLimit</code>=== @@ -64,3 +63,9 @@ This BIP is presumed deployed and activated as of block height 449568 by impleme The first block larger than 1M will create a network partition, as nodes with a fixed 1M hard limit reject that block. +==Reference Implementation== +https://github.com/bitcoinxt/bitcoinxt/pull/188 + +==Copyright== +This document is licensed under the BSD 2-clause license. + |