BUIP055: Increase the Block Size Limit at a Fixed Block Height
Proposer: Peter Rizun
Submitted on: 2017-05-10
Status: draft


## 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 8 MB limit at block #488,888 (~18 October
2017).

## 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=1000000] is the block size limit presently enforced, measured in bytes,

new_limit [default=8000000] is the new block size limit, measured in bytes, and

activation_height [default=488888] 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)
{
max_block_size =
(block_height < activation_height) ? current_limit : new_limit;
}
else
{
...other logic
}

### Signature operations and transaction size

The maximum signature operations and transaction size are consistent
with BUIP040 and
BIP100:

max_block_sigops = 20000*((max_block_size-1)/1000000 + 1)

max_tx_size = 1000000

### 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

"(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/EB8@488888/"

"BitcoinUnlimited:1.1.0(EB1;EB8@488888)"

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 8 MB at block #488,888
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-analyt…chain-with-two-block-size-limits-5642ab0325dc