BIP: 10X (not assigned a BIP number yet) Title: Hybrid Mechanism Adjusting Block Size Limit Author: Michael_S user of bitcointalk.org Discussions-To: https://bitcointalk.org/index.php?topic=1166970.0 Discussions-To: https://www.reddit.com/r/Bitcoin/comments/3jvb0i/bip10x_a_hybrid_mechanism_for_blocksizelimit/ Status: Draft Type: Standards Track Created: 2015-08-31
- Reference to fullly detailed specification incl. simulation results (~40 pages):
- BIP10X_Block_Size_Limit_Adaptation_v02.pdf - scribd.com
- BIP10X_Block_Size_Limit_Adaptation_v02.pdf - dropbox download
- Copyright notice:
- This document is placed in the public domain
This BIP proposes replacing the fixed one megabyte block size limit with a dynamically controlled block size limit that may increase or slowly decrease in ~1 week intervals. The adaptive adjustment of block size limit depends on different criteria (CRIT) and constraints (CNST), which are:
- Continuous miner votes in every block, evaluated in 1-week intervals (CRIT)
- Actual average occupancy of blocks in the same 1-week voting intervals (CNST)
- Limits on long-term change rate of the block size limit (CNST)
- Treatment of short-term peaks in TX load (CRIT/CNST)
More details with concrete implementation guidelines, formulas/algorithms, illustrative figures, simulation code, simulation results, and with more detailed rationale on all design choices, are contained in a ~40 pages PDF document that is linked from this BIP's thread on bitcointalk.org for now. It might be moved to a separate Github file at a later point in time.
With increased adoption, transaction volume on Bitcoin network is bound to grow. If the one megabyte BlockSizeLimit is not changed to a flexible one which adapts to changing network demand and technological progress, Bitcoin adoption will slow down and the Bitcoin experiment may eventually fail. Following graph shows the change in average block size since inception:
This BIP permanently incorporates miner voting about the block size limit into the protocol. Such a solution is considered preferrable over a solution where “de-facto voting” is done (within a protocol that does not actually support voting) by introducing hard-forks into the network and let miner majority decide upon acceptance/activation (="de-facto voting").Integrating voting into the protocol should appease the minds and make future adaptations of the BlockSizeLimit a normal process within the protocol, based on market demands and technological evolution. It should give planning security to all stakeholders, while developers can re-focus on other important improvements. Constraints and growth rate limits further improve planning security by avoiding sudden swings of the BlockSizeLimit by definition of the protocol.
So, unlike with BIP100, no overarching control is given to miner votes. Instead, actual block occupancy is taken into consideration by providing a tolerance interval that saturates votes which would otherwise be too far off. Another fixed tolerance span is defined by the constraint for long-term growth rate of the BlockSizeLimit; this avoids too arbitrary variations. However, unlike BIP101 with its pre-defined fixed growth rate, this BIP protocol does allow adaptation to long-term evolution of markets and technologies, which cannot be predicted from today into all future.
This BIP therefore solves the most criticized points of the two most popular BIP proposals for the block size limit issue, namely BIP100 and BIP101, and shows a path that takes into account concerns against BIP100 and BIP101 widely expressed by the community and seen by the author himself. Thanks to the way how this BIP is carefully constructed, it is not a "rotten compromise" but a fully independent solution that combines the best ideas and properties of BIP100 and BIP101 while eliminating their greatest drawbacks. Thereby it is hoped to achieve the greatest community consensus.
Finally, the motivation of this BIP is also to have means for “elastic” reaction to temporary short-term traffic increase in the Bitcoin network while avoiding mis-use by sufficient counter-incentive. While this "elasticity feature" implementation-wise does not interfere with the other features of this BIP, it was still decided to include it into this BIP to get what the author considers the most complete package to tackle the BlockSizeLimit issue.
This BIP proposes a combination of several carefully designed features:
Miner votes determine the initial block size limit with 80% majority at the start of protocol activation during the first ~1 week (1008 blocks) vote period. This initial vote is constrained to 1..4 Mbytes. Note: Regular vote one week later can already increase this initial value further by 41% (50% majority), or even double it within 2 weeks (80% majority), see "Part 3" below.
While miners cast their votes continually in every single block, votes are evaluated every 1008 blocks (=one week =half of a difficulty adjustment interval). For simplicity, miners can be configured by the operators to vote for a fixed amount, for a fixed factor relative to average actual block size, or to vote for "no change" relative to the current BlockSizeLimit.
The effective vote is set to be the median (50% quantile) of all 1008 miner votes.
Special: An 80% majority (20% or 80% quantile respectively) has the power to “boost” the long-term growth (or decline) rate by a speed-up factor of 2, see "Part 3" below.
The protocol checks the miner votes against the average actual block size (aABS) during the same voting interval. If the discrepancy is too great, the protocol overrules the effective vote by “forcing” it into a carefully designed tolerance-interval around the average actual block size:
Interval = [1.21 ; 4.59]*aABS.
The miner vote (i.e. the possibly "corrected" vote acc. to "Part 2") is further constrained to avoid a too fast growth or decline on the long run. For this, the long-term averaged block size limit (roughly 1-1.5 year average, determined by simple exponential window averaging with 62.5 weeks "effective window length") is taken into account, and the new BlockSizeLimit is forced to respect the min/max growth rates of +41% p.a. / ‑8% p.a. (i.e. factor x2 each 2 years, factor x0.5 each 8 years).
In case of a 80% vote majority for one direction, more relaxed constraints are applied to the long-term evolution: In this case the limits are +100% p.a. / ‑16% p.a. (i.e. factor x2 each 1 year, factor x0.5 each 4 years).
The TOTAL min/max limits on BlockSizeLimit are set to 1 MB and 60.1 GB respectively. The value of 60.1 GB is the result of the concrete implementation proposal of the voting format and is not expected to be met any time soon, if ever (even theoretically(!), it cannot be reached before 2043, or before 2029 with continuous >80% miner support [assuming 10min block times and the greatest possible starting BlockSizeLimit of 4 MB]).
Block sizes are signalled by 7 bits (x = 0..127), signifying values of 2^(x/8) Mbytes. This means that 128 distinct block sizes between 1 MB and 60.1 GB can be voted for, in incremental steps of ca. +9.05%.
Side note: One bit is reserved in the defined voting format. When simply releasing this spare bit, max. BlockSizeLimit will rise to 3939 TB, which is enough to accomodate 1 TX per second per each person on earth, assuming 10 Billion people.
In exceptional cases of temporary high traffic load, blocks are allowed to exceed the nominal BlockSizeLimit by up to a factor of 4. The occurrence of such “overbooked” blocks is limited to 30% and even stricter to only 10% for blocks more than 2 times above BlockSizeLimit (exponentially averaged over roughly 3-5 months).
Counter-incentive: Miners have to burn (spend to unspendable address "1BitcoinEaterAddressDontSendf59kuE") 25% of TX fees attributed to transactions in excess of the nominal BlockSizeLimit as determined by parts 0-4 (detailed formula available in the full spec).
Votes and some other information needed for this BIP are included in unused parts of the block header's 32-bit version number field. All details like definition of bit fields are available in the full spec.
The rationale for using miner voting in the first place is to "institutionalize" a voting mechanism inside the protocol. This will avoid that "de-facto" voting is taking place in the future via hard-forks for BlockSizeLimit adaptations while the deployed SW itself does not support any voting. While BIP100 already proposes miner voting, it has some drawbacks in the way how it is specified in detail. These drawbacks are removed by this "BIP10X".
Instead of fixing the start BlockSizeLimit upfront, it is more consistent with the overall idea to leave this decisions to the miners. Limits of 1 to 4 MB are set to avoid mis-use. The 80% requirement is chosen to respect the needs of more conservative miners for this initial irrevocable decision, to avoid too much disruption when this BIP is introduced.
Traffic usage is expected to vary with patterns of weekly periodicity (working days, weekends). Hence a 1 week (1008 blocks) voting interval is chosen. Probably for the same reason, Satoshi has chosen 2 weeks (2016 blocks) for the difficulty adjustment interval.
"Quantile" vote evaluation instead of "averaging" of votes is chosen to avoid the possibility (or need) for "tactical voting", which would reduce fairness and bring undesired elements of gamble into the voting process (like voting more extreme than desired by oneself to offset other extreme votes on the "other side").
The threshold=50% is chosen because this is the BlockSizeLimit that is not too large for 50% of votes and not too small for 50% of votes, hence most fair. 80% majority for stretching the limits of long-term growth (or decline) beyond the normal limits is chosen to keep a door open for faster evolution, if needed, while making abuse difficult.
This constraint is introduced because miner votes should not stand against reality. This is a reality-check, so if miners produce almost empty blocks and at the same time vote for an increase, or if miners produce almost full blocks but vote for a decrease, this is considered inconsistent by the protocol. In this case, the effective vote is forced into an interval that is determined by actual block size.
This interval is defiend to be between 1.21 and 4.59 times the average actual block size and thereby becomes relevant only if the average actual block size lies outside of an interval that is 20%..90% of current BlockSizeLimit.
Note that in a sense the average actual block size also reflects "miner votes", because it is up to the miners to decide how much a block gets filled.
The max growth rate limit of 41% p.a. is taken from the optimistic growth rate assumption of BIP101. The "boosted" limit of 100% p.a. (for 80% miner majority) is taken as a precaution, should not even the 41% be enough. The ‑8% decline rate limit is chosen because it opens up the general possibility to decrease BlockSizeLimit for whatever reason. However, times of low traffic should not pre-maturely cause a too quick decline that makes it difficult to later come back to the earlier value, hence the decline rate is limited much stricter than the growth rate (factor 2 is only achieved in 8 instead of 2 years). The ‑16% decline rate achievable for 80% miner majority realizes the same factor 2 speed-up (relative to 50% majority) as for the growth rate case.
This long-term growth/decline constraint is the strongest constraint, it potentially overrules the miners' votes and also the contraint of part 2, thereby avoiding miner abuse, stabilizing the system and allowing long-term planning security – no sudden surprises are possible, because BlockSizeLimit can only change at limited pace and in small steps. Should miners behave unreasonable, the community has enough time to react (e.g. by moving to other mining pools), before miners can cause any measurable harm.
This stabilizes the system, which is of advantage for both miners and other stake holders and thereby beneficial for the Bitcoin eco-system as a whole.
These limits are the result of the bit-accurate protocol specification, and as such they provide a huge signaling range that should be future proof till eternity, while still requiring only few bits and providing a sufficiently fine granularity for the votes.
This mechanism introduces a certain degree of elasticity to avoid being "helpless" in case a huge amount of transaction volume is unexpectedly hitting the Bitcoin network.
The maximum overbooking factor (x4), the limit on blocks allowed to be "overbooked" (10%, 30%) and the counter-incentive (proof of burn of 25% of "excess" TX fees) are introduced to avoid abuse and to really make sure that the nominal BlockSizeLimit is obeyed under all normal circumstances.
The decision to burn these bitcoins instead of making them available to later miners by a "rollover pool" (as suggested by Meni Rosenfeld) is mainly due to simplicity: It is assumed that this is an exceptional mechanism (and less and less needed the more Bitcoin matures in the future when block rewards half), so there is not much benefit in making the protocol overly complicated here, just to avoid reducing the overall miner rewards by burning TX fees.
(Another reason is that, when miners are seen as one collective group, then with the "rollover" mechanism all penalties would eventually go back to the miners anyway, so there would not be any counter-incentive when considering the miners collectively. With the "proof of burn" mechanism favored by this BIP, there really is a collective counter-incentive against overbooked blocks.)
The signaling format is fully specified in bit-exact manner, it is simple and yet very efficient in usage of bit space in the block header.
The reason for putting all information of this BIP (particularly the votes) into the header is given by Gavin Andresen in his BIP101 proposal's comment on BIP100:
- “[...] [Having BIP100's vote in the coinbase scriptSig] is more complex to implement [than BIP101's solution to only have a modification in the header], because [with BIP100] the maximum allowed size for a block depends on information contained in coinbase transactions from previous blocks (which may not be immediately known if block contents are being fetched out-of-order in a 'headers-first' mode)”
The version number field itself has 32 bits, which is much more than what is actually needed. Hence, two unused bytes of this field are used for this BIP's purposes without any negative side effects.
This is a hard-forking change to the Bitcoin protocol. Anybody running code that fully validates blocks must upgrade before the end of the grace period after the activation time of this BIP. Otherwise, the other miner will no more be able to work on the miner majority's longest chain.
SPV wallets are not affected and require no change or update.
Software that is compliant with this BIP can be deployed any time. As soon as a 75% supermajority is achieved (same percentage as proposed in BIP101), the protocol irrevocably decides that the changes of this protocol will activate after a 2-3 week grace period, leaving other miners sufficient time for upgrading to the new protocol version.
If implementation and testing of this BIP10X takes too long while actual block sizes are alredy approaching current block size limit, then time should be gained by temporarily raising block size limit to 2 MB via BIP102, before finally deploying this BIP10X.
- Jeff Garzik for proposing a miner voting mechanism for BlockSizeLimit via BIP100.
- Gavin Andresen for proposing a fixed growth rate solution for BlockSizeLimit via BIP101.
- All participants of pragmatic proposals and discussions around BlockSizeLimit evolution.
- All Bitcoin developers since 2008/2009 for enabling this discussion in the first place.
Making Decentralized Economic Policy v0.8.1 (Latest version on Github) - BIP100 by Jeff Garzik
Increase maximum block size - BIP101 by Gavin Andresen
Increase block size limit to 2MB - BIP102 by Jeff Garzik
Block size following technological growth - BIP103(?) by Pieter Wuille
Dynamically Controlled Bitcoin Block Size Max Cap - BIP1xx by Upal Chakraborty
Elastic block cap with rollover penalties - by Meni Rosenfeld
- Further References:
- Bitcoin Network Capacity Analysis - Part 4: Simulating Practical Capacity
- A summary of block size hard fork proposals - (lists.linuxfoundation.org)