login
BUIP056: Increase the Block Size Limit at a Support Threshold
Proposer: Tomas van der Wansem
Sponsor: Zangelbert Bingledack
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
    adjustment with a 75% threshold.
  • 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.