BIP 0100
This page describes a BIP (Bitcoin Improvement Proposal). |
Please do not modify this page. This is a mirror of the BIP from the source Git repository here. |
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> Dagur Valberg Johannsson <dagurval@pvv.ntnu.no> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100 Status: Rejected Type: Standards Track Created: 2015-06-11 License: BSD-2-Clause
Abstract
Replace the static 1M block size hard limit with a hard limit set by coinbase vote, conducted on the same schedule as difficulty retargeting.
Motivation
Miners directly feel the effects, both positive and negative, of any maximum block size change imposed by their peers. Larger blocks allow more growth in the on-chain ecosystem, while smaller blocks reduce resource requirements network-wide. Miners also act as an efficient proxy for the rest of the ecosystem, since they are paid in the tokens collected for the blocks they create.
A simple deterministic system is specified, whereby a 75% mining supermajority may activate a change to the maximum block size each 2016 blocks. Each change is limited to a 5% increase from the previous block size hard limit, or a decrease of similar magnitude. Among adopting nodes, there will be no disagreement on the evolution of the maximum block size.
The system is compatible with emergent consensus, but whereas under that system a miner may choose to accept any size block, a miner following BIP100 observes the 75% supermajority rule, and the 5% change limit rule. Excessive-block values signaled by emergent consensus blocks are considered in the calculation of the BIP100 block size hard limit, and the BIP100 calculated maximum block size is signaled as an excessive-block value for the benefit of all observers.
Specification
Dynamic Maximum Block Size
- Initial value of
hardLimit
is 1000000 bytes, preserving current system. - Changing
hardLimit
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.
- Vote encoding
- A vote is represented as a megabyte value using the BIP100 pattern
/BIP100/B[0-9]+/
Example:/BIP100/B8/
is a vote for a 8000000-bytehardLimit
. - 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 megabyte value is represented by consecutive base-ten digits.
- If no BIP100 pattern is matched, the first matching emergent consensus pattern
/EB[0-9]+/
, if any, is accepted as the megabyte vote.
- A vote is represented as a megabyte value using the BIP100 pattern
- Maximum block size recalculation
- A
new hardLimit
is calculated after each difficulty adjustment period of 2016 blocks, and applies to the next 2016 blocks. - Absent/zero-valued votes are counted as votes for the
current hardLimit
. - The votes of the previous 2016 blocks are sorted by megabyte vote.
- Raising
hardLimit
- The
raise value
is defined as the vote of the 1512th highest block, converted to bytes. - If the resultant
raise value
is greater than (current hardLimit
* 1.05) rounded down, it is set to that value. - If the resultant
raise value
is greater thancurrent hardLimit
, theraise value
becomes thenew hardLimit
and the recalculation is complete.
- The
- Lowering
hardLimit
- The
lower value
is defined as the vote of the 1512th lowest block, converted to bytes. - If the resultant
lower value
is less than (current hardLimit
/ 1.05) rounded down, it is set to that value. - If the resultant
lower value
is less thancurrent hardLimit
, thelower value
becomes thenew hardLimit
and the recalculation is complete.
- The
- Otherwise,
new hardLimit
remains the same ascurrent hardLimit
.
- A
- Vote encoding
Signature Hashing Operations Limits
- The per-block signature hashing operations limit is scaled to (actual block size, fractional megabyte rounded to next higher megabyte) / 50.
- A maximum serialized transaction size of 1000000 bytes is imposed.
Recommendations
Publication of hardLimit
- For the benefit of all observers, it is recommended that
hardLimit
be published. Example: a complete coinbase string might read/BIP100/B8/EB2.123456/
which indicates a vote for 8M maximum block size, and an enforcedhardLimit
of 2.123456 megabytes for the block containing the coinbase string.
Deployment
This BIP is presumed deployed and activated as of block height 449568 by implementing nodes on the bitcoin mainnet. It has no effect until a raise value different from 1M is observed, which requires at least 1512 of 2016 blocks to vote differently from 1M.
Backward compatibility
The first block larger than 1M will create a network partition, as nodes with a fixed 1M hard limit reject that block.
Implementations
https://github.com/bitcoinxt/bitcoinxt/pull/188
https://github.com/bitcoinxt/bitcoin/pull/1
https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/398
Copyright
This document is licensed under the BSD 2-clause license.