BUIP055: Increase the Block Size Limit at a Fixed Block Height
Proposer: Peter Rizun
Submitted: 2017-05-10
Abstract
This BUIP proposes to add functionality to automatically increase a node's block size limit at a specified block height. The default settings correspond to an 2 MB limit at block #494,784.
Motivation
Due to the 1 MB block size limit enforced by many mining and non-mining nodes, miners can no longer respond to increasing demand for Bitcoin transactions by increasing the supply of block space. This has resulted in a sharp increase in transaction fees and has made transaction confirmation times unreliable.
To alleviate this condition, node operators and miners must increase the maximum size of blocks their nodes accept. The deployment of BUIP001 gave both groups the ability to increase their nodes' block size limits without restarting the client or recompiling executables from source code.
With the benefit of hindsight, it has become clear that BUIP001 was a success with operators of non-mining nodes: the median block size limit enforced by non-mining nodes running Bitcoin Unlimited is now 16 MB.
However, BUIP001 has been less successful with miners: the median block size limit enforced by miners running Bitcoin Unlimited is still 1 MB, despite the fact that a majority of the network hash power wants to mine larger blocks. Empirical evidence suggests that miners are typically unwilling to act independently, instead favoring to increase their nodes' block size limits in unison with the other miners.
What is needed then is a simple coordination scheme to permit miners to increase their nodes’ block size limits in lock step. The specification described in this proposal is one such coordination scheme.
Specification
Block size limit
If a node operator elects to use BUIP055, three variables must be defined: current_limit, new_limit and activation_height, where
with the requirement [1] that
The maximum block size (max_block_size) for a given block is then calculated using the following logic:
Signature operations and transaction size
The maximum signature operations for a given block and the maximum transaction size are consistent with BUIP040 and BIP100:
where this_block_size is the size of the block being checked (and of course this_block_size <= max_block_size).
Coinbase and user-agent signalling
Building on the format specified in BUIP005, the relevant variables are signalled in the coinbase transaction as
and in the user-agent string as
For example, using the default settings (and assuming AD is not signalled), the following strings would be included in the coinbase transaction and the user-agent string, respectively:
Note that the current and new block size limits are signalled in units of megabytes. Refer to BUIP005 for further information.
Re-org protection
Re-org protection shall be implemented to prevent the big-block chain from re-organizing back to the small block chain, should the small-block chain temporarily become longer. This will be accomplished by adding a temporary protocol rule for nodes that elect to use BUIP055, which requires the size of the block at the activation_height to have a size greater than the current_limit:
Once the network upgrade is complete and the small-block chain is extinguished (or no longer a threat of catching up), this temporary rule can be removed.
It is important to note that the block production code must also be extended to ensure that a block greater than the current limit is actually produced by mining nodes at the activation height.
Rationale for Re-org Protection
The probability (P) that the big-block chain re-orgs back to the small-block chain is given by
where p is the fraction of the hash power mining the big-block chain and q is the fraction of the hash power remaining on the small block chain [2]. With 75% of the hash power supporting larger blocks, the probability of a re-org is 11%. An unlucky re-org would result in the loss of all block rewards mined on the big-block chain, and a possible loss of momentum for the network upgrade. Communication with miners indicates that they want protection to mitigate this risk, given the current level of contention in the Bitcoin community.
Deployment
Miners can begin signalling for an increase to 2 MB at block #494,784 immediately, or modify the defaults to propose a different limit or activation height. If a sufficient fraction of the network hash power supports a given proposal, no further action is required: the network's block size limit will be automatically increased at the agreed-upon block height. If sufficient support is not obtained, then miners could modify their proposals (e.g., by pushing the activation date further into the future or by proposing a different block size limit) and try again.
Backwards compatibility
If a block larger than 1,000,000 bytes is mined into the most-work chain, nodes that continue to enforce the legacy block size limit will not recognize it as valid and ignore it. If the minority chain has non-negligible hashing power, the blockchain will bifurcate at that point.
[1] Reindexing the chain could fail if the block size limit were repeatedly decreased without keeping track of prior block size limits.
[2] https://medium.com/@tl121/an-analytic-model-of-the-performance-of-a-forked-bitcoin-blockchain-with-two-block-size-limits-5642ab0325dc
Proposer: Peter Rizun
Submitted: 2017-05-10
Abstract
This BUIP proposes to add functionality to automatically increase a node's block size limit at a specified block height. The default settings correspond to an 2 MB limit at block #494,784.
Motivation
Due to the 1 MB block size limit enforced by many mining and non-mining nodes, miners can no longer respond to increasing demand for Bitcoin transactions by increasing the supply of block space. This has resulted in a sharp increase in transaction fees and has made transaction confirmation times unreliable.
To alleviate this condition, node operators and miners must increase the maximum size of blocks their nodes accept. The deployment of BUIP001 gave both groups the ability to increase their nodes' block size limits without restarting the client or recompiling executables from source code.
With the benefit of hindsight, it has become clear that BUIP001 was a success with operators of non-mining nodes: the median block size limit enforced by non-mining nodes running Bitcoin Unlimited is now 16 MB.
However, BUIP001 has been less successful with miners: the median block size limit enforced by miners running Bitcoin Unlimited is still 1 MB, despite the fact that a majority of the network hash power wants to mine larger blocks. Empirical evidence suggests that miners are typically unwilling to act independently, instead favoring to increase their nodes' block size limits in unison with the other miners.
What is needed then is a simple coordination scheme to permit miners to increase their nodes’ block size limits in lock step. The specification described in this proposal is one such coordination scheme.
Specification
Block size limit
If a node operator elects to use BUIP055, three variables must be defined: current_limit, new_limit and activation_height, where
current_limit [default=[FONT=Courier New]1000000[/FONT]] is the block size limit presently enforced, measured in bytes,
new_limit [default=[FONT=Courier New]2000000[/FONT]] is the new block size limit, measured in bytes, and
activation_height [default=[FONT=Courier New]494784[/FONT]] is the block number when the new limit applies,
with the requirement [1] that
new_limit >= current_limit > 0.
The maximum block size (max_block_size) for a given block is then calculated using the following logic:
if(BUIP055)
{
else
{
{
max_block_size =
}(block_height < activation_height) ? current_limit : new_limit;
else
{
...other logic
} Signature operations and transaction size
The maximum signature operations for a given block and the maximum transaction size are consistent with BUIP040 and BIP100:
max_block_sigops = 20000*((this_block_size-1)/1000000 + 1)
max_tx_size = 1000000
max_tx_size = 1000000
where this_block_size is the size of the block being checked (and of course this_block_size <= max_block_size).
Coinbase and user-agent signalling
Building on the format specified in BUIP005, the relevant variables are signalled in the coinbase transaction as
"/EB<current_limit_MB>/EB<new_limit_MB>@<activation_height>/..."
and in the user-agent string as
"<user-agent>(EB<current_limit_MB>;EB<new_limit_MB>@<activation_height>...)/"
For example, using the default settings (and assuming AD is not signalled), the following strings would be included in the coinbase transaction and the user-agent string, respectively:
"/EB1/EB2@494784/"
"BitcoinUnlimited:1.1.0(EB1;EB2@494784)
"BitcoinUnlimited:1.1.0(EB1;EB2@494784)
Note that the current and new block size limits are signalled in units of megabytes. Refer to BUIP005 for further information.
Re-org protection
Re-org protection shall be implemented to prevent the big-block chain from re-organizing back to the small block chain, should the small-block chain temporarily become longer. This will be accomplished by adding a temporary protocol rule for nodes that elect to use BUIP055, which requires the size of the block at the activation_height to have a size greater than the current_limit:
min_block_size = (block_height==activation_height) ? current_limit+1 : 0;
Once the network upgrade is complete and the small-block chain is extinguished (or no longer a threat of catching up), this temporary rule can be removed.
It is important to note that the block production code must also be extended to ensure that a block greater than the current limit is actually produced by mining nodes at the activation height.
Rationale for Re-org Protection
The probability (P) that the big-block chain re-orgs back to the small-block chain is given by
P = (q/p)^2
where p is the fraction of the hash power mining the big-block chain and q is the fraction of the hash power remaining on the small block chain [2]. With 75% of the hash power supporting larger blocks, the probability of a re-org is 11%. An unlucky re-org would result in the loss of all block rewards mined on the big-block chain, and a possible loss of momentum for the network upgrade. Communication with miners indicates that they want protection to mitigate this risk, given the current level of contention in the Bitcoin community.
Deployment
Miners can begin signalling for an increase to 2 MB at block #494,784 immediately, or modify the defaults to propose a different limit or activation height. If a sufficient fraction of the network hash power supports a given proposal, no further action is required: the network's block size limit will be automatically increased at the agreed-upon block height. If sufficient support is not obtained, then miners could modify their proposals (e.g., by pushing the activation date further into the future or by proposing a different block size limit) and try again.
Backwards compatibility
If a block larger than 1,000,000 bytes is mined into the most-work chain, nodes that continue to enforce the legacy block size limit will not recognize it as valid and ignore it. If the minority chain has non-negligible hashing power, the blockchain will bifurcate at that point.
[1] Reindexing the chain could fail if the block size limit were repeatedly decreased without keeping track of prior block size limits.
[2] https://medium.com/@tl121/an-analytic-model-of-the-performance-of-a-forked-bitcoin-blockchain-with-two-block-size-limits-5642ab0325dc
Last edited:
