Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
132 lines (82 sloc) 14.8 KB

  Title: Maximum Block Size Consensus Rule Based On Median Block Size
  Author: Stephen Pair <>, Chris Kleeschulte <>
  Status: Draft
  Type: Standards Track
  Created: 2016-02-25

Table of Contents


We propose a dynamic limit to the block size based on the median block size over the last 12,960 blocks (about three months) multiplied by 2 and calculated when a block is connected to the blockchain.


The purpose of this consensus rule change is to allow the maximum block size to increase or decrease based on actual network usage. A block size limit, as discussed here, prevents certain types of denial of service attacks on the Bitcoin network, however a fixed limit does not allow the capacity of the network to increase as advancements in scaling are realized. By adjusting the limit based on the sizes of blocks in the recent past, the throughput of the network can adjust to changes in user demand and scaling related technology advancements while still being protected from denial of service attacks.

This is a chain-based signaling mechanism that will allow miners to have certainty that the blocks they build will be accepted by the rest of the network. With this BIP in place, future hard forks related to block size should be unnecessary.

Please note that this proposal DOES NOT propose a blended cost metric for transactions and blocks used for miner transaction selection. Consensus rules regarding maximum signature operations per block and maximum standard transaction signature operations should be considered separately from this consensus rule change. A recommendation would be to adaptively adjust those limits in a manner similar to this proposal.


  • This is implemented as a hard fork using version bits for activation.

  • After 75% of livenet nodes (and 51% of testnet) begin using this BIP's version bits:
    • The new maximum block size calculation will take place at the end of ConnectBlock(), so enforcement of the new maximum block size consensus rule will take place on the next block received.
    • Using a pre-sorted list of the last 12,960 blocks' sizes (about three months of blocks)
    • median * 2 (2 is the growth multiplier)
    • If the median is less than 500,000 bytes, then 1,000,000 bytes is used as the maximum block size until next calculation. Note: the current maximum block size consensus rule is 1,000,000 bytes.
    • A new miner option called “blockmaxpercentage” will be available (not yet in implementation). This option will deprecate “blockmaxsize”. If blockmaxpercentage is used, then miners can designate blocks to be from 0-100% of the calculated maximum block consensus rule. Example, if bitcoind is started with -blockmaxpercentage=99, then whatever the maximum block size was calculated to be when the last block was connected, then the new block will be 99% of this value (if memory pool conditions exist). If only the blockmaxsize option is specified, it will be used to compute a percentage relative to the current 1,000,000 bytes limit. The default blockmaxpercentage is 75.
    • It is our intention to be unambiguous about how a median is found in a list of block sizes. An example implementation in C++ of the retreiving the median block size:
unsigned int vsize = blocksizes.size(); //blocksizes is std::vector<unsigned int>
if (vsize == pastblocks) {
  double median = 0;
  if ((vsize % 2) == 0) {
    median = (blocksizes[vsize / 2] + blocksizes[(vsize / 2) - 1]) / 2.0;
  } else {
    median = blocksizes[vsize / 2];
  return static_cast<unsigned int>(floor(median));
} else {
  return 0; 


Activation: 75% hash power trigger (livenet), 51% hash power (testnet)

Miners express their support for this BIP by setting the fifth-highest-bit in the block's 32-bit version number (0x08000000 in hex). The “IsSuperMajority()” static method will be used to decide when to trigger this BIP. This is the same method of invocation used by BIP66 and BIP65. Should the “IsSuperMajority()” method return true, this will trigger the recalculation of maximum block size, maximum block signature operations, and maximum standard transaction signature operations. Backward compatibility

Fully validating older clients are not compatible with this change. The first block exceeding the old limits on block size will partition older clients off the new network.

SPV (simple payment validation) wallets are compatible with this change.


By having a maximum block size that adjusts based on the median block size of the past blocks, the degree to which a single miner can influence the decision over what the maximum block size is directly proportional to their own mining hash rate on the network. The only way a single miner can make a unilateral decision on block size would be if they had greater than 50% of the mining power. In this case, Bitcoin has existential problems beyond the scope of this BIP. Using the median block size multiplied by 2 achieves predictable growth in the max block size over time. See Figure 1.

Figure 1 shows an overall rise in the maximum block size over time (orange line). This shows how the maximum block size consensus rule would have changed over time had this BIP been in place, but miners chose to not to exceed the current maximum block size consensus rule.

Choosing the median block size versus using an arithmetic mean is an important design decision. Using the moving average over the look back period to calculate the maximum block size consensus rule would allow individual miners to influence this consensus rule in a way that is not proportional to their historical hash rate on the network. In other words, a single miner could have a disproportionately large influence over the block size limit by building very large or very small blocks.

Supporting Analysis

In preparation for this proposal, we looked at a number of block size growth functions. If you would like to see some of this analysis, please check out these graphs. We decided that a look back of 12,960 blocks (about three months) and a multiple of 2 worked well to react as quickly as possible to market forces while not being overly volatile. Except in extremity, other choices for a look back period would work just as well. By calculating the maximum block size with each block (rather than on some interval), the limit adjusts more smoothly.

Projected Future Block Size Increases

In essence, the purpose of this change to the consensus rules is to give the miners more choice in the size of the blocks created. Some miners will see the benefit in building larger blocks to minimize transaction confirmation times while other miners will choose to be more conservative.

Worst Case Growth Scenarios

The maximum rate of growth is capped at the growth multiplier, which is 2. So, worst case scenario can occur if every block is mined to capacity continuously over time. In this case, the absolute fastest growth rate is a doubling of maximum block size every 6480 blocks (45 days). Miners wish to maximize the sum of transaction fees paid for blocks they mine, while at the same time keep individual transaction fees as low as possible to allow Bitcoin to be more competitive as a payment network.

SPV Mining Ramifications

We don’t expect this consensus rule change to impact miners who choose to mine from block headers before the full block is transferred, validated and connected to the active chain. The same behavior will be observed before and after this change. Since this consensus rule will be calculated as a precondition to ConnectBlock(), the maximum block size rule for the next block will not be known until after the last block is connected to the main chain.

Should the growth rate of the block size limit exceed the actual capacity of the Bitcoin network, there should be an increase in the number of empty blocks as a result of SPV mining. The effect of which would be to reduce the median block size and therefore reduce the block size limit. To the extent miners engage in SPV mining, it should have an automatic, self correcting effect on the block size limit.


  1. Will this proposal result in constant growth of the maximum block size at the maximum rate (Worst Case Scenario)?
    1. This is unlikely because of the limitations of technology. A miner can try and transmit larger and larger blocks up until he starts feeling the pinch of orphaned blocks, which should start happening as it begins taking longer for other miners to validate blocks. As they see increased orphan rates, a miner would dial back their own max block size.
  2. Is it possible for the maximum block size consensus rule to drop below the current rule of 1,000,000 bytes under this proposal?
    1. No, this proposal states that the maximum block size consensus rule will never drop below 1,000,000 bytes. Miners can build any size blocks they want, but the rule states that the maximum block size will not be lower than 1,000,000 bytes.
  3. Why should the maximum block size consensus rule be computed every time a block is connected to the active chain? Why not every 144 blocks or 2016 blocks, etc.?
    1. Quite simply, the decision to calculate the maximum block size after each block was the least arbitrary of the all options available to us. In other words, we considered the choice of calculating the maximum block size at alternate intervals to be more arbitrary than every block for no gain.
  4. How would this proposal affect miners' behavior? More specifically, how does this affect miners that begin hashing using the last reported successfully mined block header only?
    1. We don't think that SPV miners will be affected by this proposal. This proposal posits that block size increases will happen in response to the need to process transactions on the Bitcoin payment network but be moderated by limitations of current technology. Example, miner A builds a large block and propagates it. Miner B has very limited hardware and/or network capabilities. Miner B chooses to mine from miner A's block header only and actually finds the next block (this happens at the present time). Miner B does not have the ability to add any transactions from their memory pool for fear they appeared in the last block. So, miner B mines a block with only the coinbase transaction. This very small block will then be a factor in lowering the maximum block size consensus rule in the immediate future.
  5. Will this proposal lead to a change in incentives for miners? If so, how?
    1. This was one of our main concerns in developing this proposal. We don't think miner incentives will change at all. The chances of a miner (or pool) building the next valid block is directly portional to their percentage of hashing power on the network. Similarly, the degree to which a miner (or pool) can influence what the maximum block size consensus rule is also directly proportional to their hashing power on the network.
  6. Can this proposal be triggered with a minority of miner support due to the way you are suggesting activation?
    1. This proposal will become active when 750 of the last 1000 blocks contain the block version bit of this proposal. We think this approach provides a great deal of confidence that a majority of the hashing power have specifically adopted this proposal. A higher percentage risks giving a single large miner a veto over the rule change. Additionally, the fact that a miner says it supports a change doesn’t mean they actually will. It is only a signaling mechanism that allows miners to indicate to each other when it is reasonably safe to adopt the new rule. If the network doesn’t actually support the new rule, the first miner to produce a block that forks the chain will end up with an orphaned block. They will quickly revert to the old rules upon observing the lack of support.
  7. What about "weak blocks"; could the development of this technology invalidate the assumption that larger blocks have a higher orphan risk?
    1. While validation and propagation times might be significantly improved by weak blocks, adding transactions to a block has a cost and will always have a cost. The orphan risk might not come directly from the cost of block validation, but from miners choosing a different block to build upon. Imagine you're a miner and two blocks arrive at close to the same time and one block has a lot of transactions and another block has very few. You may rationally choose to build on the smaller block not because of validation cost, but because it would allow you to claim some of the transaction fees that the larger block has claimed. # What about consideration of systems used in other cryptocurrencies like Meni Rosenfeld's flexcap system in Monero?
    2. The simplicity of using the multiple of median block size over a look back range was very attractive to us. Some of those flexcap proposals allow the block size to momentarily surge in response to high demand. We believe this is a mistake. The network cannot magically conjure up additional capacity in response to surges in demand. We believe the proper mechanism to address surges in demand is higher transaction fees during the period of the surge.
  8. Why did you choose the lookback period of 3 months and the multiple of 2?
    1. We had the goal of being as reactive as possible, while not being excessively volatile. We felt that a ~3 month look back period was the maximum amount of time to allow sufficient adaptability, while at the same time preventing excessive variability in the block size limit.
  9. What about other consensus rules that are, currently, directly derived from maximum block size such as maximum signature operations per block and maximum standard transaction signature operations? How does this proposal affect those consensus rules with respect to current rules?
    1. It doesn't. This proposal does not address other block limitations because we believe they should have independent limits. However, we do believe that you could employ a very similar, if not identical, approach to those limits. A combined cost metric (based a transaction’s percentage consumption of each limit) could be devised that would facilitate miner transaction selection (as well as relay policies on the mesh network). It was noted by a reviewer of this BIP that this is a manifestation of the multidimensional knapsack problem.



This work is placed in the public domain.

You can’t perform that action at this time.