75% of miners must vote for increase or decrease for a block size change to take effect.
BIP100 replaces the static 1MB block size limit in Bitcoin with a hard limit set by coinbase vote.
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.
View BIP100 - Full Specification
Voting is done in the coinbase transaction. A BIP100 vote for 8MB looks like this:
/BIP100/B8/
If there is no BIP100 vote, then a EB will be counted as a vote. So /EB8/ is also a vote for 8MB (and a promise to accept 8MB blocks).
This allows both BIP100 vote and EB signal to be present, so a BIP100 miner may publish
/BIP100/B8/EB2.1/
meaning that he votes for 8MB, but currently accepts block of size 2.1MB.
BIP100 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.
When running a non-BIP100 emergent consensus node, you keep consensus with BIP100 by:
This formula can be used to estimate how fast the block size can be increased:
n = c * 1.05^p
Where n is new limit, c is the current limit and p is number of vote periods. Each period is approximately two weeks.
Examples, given that current limit is 1MB. Numbers are rounded up:
| New limit | Vote periods | Weeks |
|---|---|---|
| 2MB | 15 | 30 |
| 4MB | 29 | 58 |
| 8MB | 43 | 86 |
| 32MB | 72 | 144 |
| 64MB | 86 | 172 |
BIP100 is implemented and will be in the next release of Bitcoin XT. In addition, BIP100 has been implemented for Bitcoin Unlimited and as a patch on top of Bitcoin Core 0.12.
Why Core 0.12? This was the last Core version without segwit code. It is straightforward to combine BIP100 and segwit if needed.