BUIP056: Increase the Block Size Limit at a Support Threshold
Proposer: Tomas van der Wansem
Submitted on: 2017-05-12
Status: draft


## Abstract

This proposal allows nodes to be configured to change their block size
limit when a support threshold is reached.

## Motivation

As outlined in the motivation for BUIP055,
the EB/AD configuration currently lacks a mechanism for miners to
coordinate changes to the max_block_size.

BUIP055 solves this by allowing miners to preannounce a change to their
max_block_size at a certain height. A drawback of that approach is
that miners cannot predict whether there is enough support among miners
for the change at the specified height.

This BUIP offers a way to change the max_block_size setting based on
support for the new value among miners. By choosing a support threshold
percentage, they can trigger a change of the block size limit guarded by
what is for them the most relevant parameter for allowing the change.

## Specification

### max_block_size calculation

To determine the max_block_size used to verify a target block, a
node will use the variables:

current_limit is the current size limit.

new_limit is the new size limit that will be activated when the
threshold is reached.

threshold is the minimum percentage of supporting blocks in a
difficulty period to trigger activation.

new_limit must be larger then current_limit and threshold must
be a multiple of 5 between 50 and 100 inclusive.

For our calculation, we define a block set as a set of blocks in a
single difficulty period at least 5 difficulty periods in the past; that
is, a set of blocks before the target block with heights between y *
2016
and (y * 2016) + 2015 inclusive, for any non-negative
integer y such that the height of the target block is larger than
(y * 2016) + 2015 + 10080.

Given a target block, let X,N be a number pair with the following
conditions:

• 2016 >= N >= threshold
• current_limit < X <= new_limit
• There exists a block set, in which at least N% of the blocks signal
a new_limit equal to or larger than X and a threshold equal to
or smaller than N. The percentage calculated should not be rounded.

If no number pair X,N exists, current_limit is used as
max_block_size for the target block. Otherwise the highest value of
X from all X,N pairs is used as the max_block_size for the target
block.

If max_block_size>1,000,000 is used for the target block and
max_block_size>1,000,000 is not used for any ancestor of the target
block and the size of the block is less then or equal to 1,000,000 then
the block must be rejected.

### 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>/FE<new_limit_MB>@%/..."

and in the user-agent string as

"(EB<current_limit_MB>;FE<new_limit_MB>@%...)/"

The variables are related as:

current_limit = current_limit_MB * 1,000,000

new_limit = new_limit_MB * 1,000,000

## Rationale

• Only block sets at least 10080 blocks deep are considered to allow
for an activation period in which more mining power can join.
• The block set is aligned with the difficulty period to minimize the
risk of a chain split. Miners are strongly disincentives to stay on
the minority as it will take at least ~8 weeks before difficulty
• The first time this mechanism is used, the chain is protected from a
reorg to the chain with only small blocks.

### Alternatives

• BUIP055 provides a coordinated max_block_size upgrade
using a target height. A drawback of this approach is that miners
cannot predict future support. A fixed hight may result in
retracting or postponing target heights due to insufficient support
which can damage reputations and cause a loss of momentum.
• BIP135 Version bit signaling can also be used to schedule based on
threshold. However version bit proposals cannot individually
encompass a minimum threshold or a maximum blocksize. This could be
solved by using multiple proposals, but voting on multiple
conflicting proposals in parallel can lead to various problems.