Skip to content

Latest commit

 

History

History
90 lines (47 loc) · 4.54 KB

056.mediawiki

File metadata and controls

90 lines (47 loc) · 4.54 KB

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

Table of Contents

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>@<threshold>%/..."

and in the user-agent string as 

        "<user-agent>(EB<current_limit_MB>;FE<new_limit_MB>@<threshold>%...)/"

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.