BUIP056: (passed) Increase the Block Size Limit triggered by a support threshold

[Tomas van der Wansem]

BUIP056: Increase the Block Size Limit triggered by a support threshold

Proposer: Tomas van der Wansem
(Based on: BUIP055 by Peter R)
Submitted: 2017-05-12
edit: sponsored by @Zangelbert Bingledack

Abstract

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

Motivation

BUIP056 is similar to BUIP055, but which I believe better may align with the requirements of miners:
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 number 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.

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.

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


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.

Alternatives

* BUIP055 provides a coordinated EC 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 threshold. This could be solved by using multiple proposals, but voting on multiple conflicting proposals can lead to complicated problems.

Changes

2015-05-13
* Changed to block count instead of percentage
* Changed EB=>FE
* Removed % from coinbase. Fixed typo
* Changed back to percentage, multiple of 5

 

[Tomas van der Wansem]

More motivation and comparison with version bit thresholds given here

https://www.reddit.com/r/btc/comments/6b32b5/buip_increase_the_block_size_limit_triggered_by_a/

 

[sickpig]

AFAIK to propose a buip that could voted you need to be a member or find member who's going to sponsor it

 

[painlord2k]

My suggestions about this BUIP:

1) Instead of a % of the blocks it would be better to signal the minimum number of blocks to trigger the increase. So other implementations don't run the risk of slightly different computations by rounding errors, etc.

2) Instead of signalling EBX@trigger, it would be better to signal FE (Future Excessive Block) just to avoid any possible confusion with the previous EB when parsing the coinbase message

3) Triggering the increase immediately when the EB get the desired majority make difficult for others (mainly business, users but also miners) to join and support the upgrade. The ability to delay the activation would give many the time to support the new block size.
So I recommend to add FD (Future Delay) to this BUIP, to allow to signal a delayed activation (recommended in multiples of 2014 blocks)

4) It is important, adding (3), to be able to abort activation if the support during this period fall under a security threshold (this to prevent activation when the majority is not large enough to minimize the chances of chain reorganization after activation).
The FE8@>1500<1200 would signal the triggering at 1500 blocks in a 2014 period, but would stop the activation if, during the FD period, the blocks go below the set threshold.

*****************************

The suggestions are meant to give the miners (and users) the ability to fully coordinate even in a scenario of a contentious HF with malicious parties acting against the successful activation of the increase of the block size.

The logic involved in coding these suggestions is surely a bit more complex, but allow to manage more complex situations.

In particular a malicious miner signalling falsely its support could not signal support, triggering an immediate increase and then causing a reorganization of the chain afterward. It would be forced to continue to signal support during all the Delay Period (or at least a large part of it), when other miners and users with a neutral stance on the issue would prepare and add their support to it.

The trigger/threshold values (useful during the delayed activation period) allow the miners to set in advance their preferred majority to smoothly activate the upgrade (the trigger) but also set the minimum majority (and the level of risks and troubles) they are willing to suffer to activate the upgrade).

A malicious miner with the intent to defect the majority after activation would know it MUST be able to drop the support under such threshold to prevent activation. Failing to do so, it just triggers the activation earlier.

 

[Tomas van der Wansem]

Thank you for your reply.

1) I chose percentages over block-count because it is not hard to calculate without rounding errors, and there is a small advantage in making the information easy to calculate by hand. I was actually thinking to change to require multiples of 5 for this reason. Block count seems to be too much granularity. However if others agree with you, I am happy to change to block count.

EDIT: I have changed this to block count. Thanks.

2) Agreed, will change.

3)4) There is already an activation period of 10 weeks, and a simple way to abort by changing your parameters during this period.

Does a *custom* activation period make sense? I like things simple.

 

[freetrader]

There is already an activation period of 10 weeks, and a simple way to abort by changing your parameters during this period.

I understood the proposal to "lock in" a matching block size increase if any sufficiently old block set (i.e. a single difficulty period, "for any non-negative integer y") meets the criteria.
Is that a wrong interpretation?
I don't see how it allows for an an abort even if subsequent block sets (which haven't aged enough yet) fall below the needed support levels...

 

[Tomas van der Wansem]

> Is that a wrong interpretation?

That is correct. It allows an "abort" by setting a higher threshold. So if there is a difficulty period with 75% of blocks voting with a threshold of >= 75%, the increase is "activated" after 10 weeks, but everyone can choose to abort by switching to a higher treshold (the criterium "100 >= N >= threshold" in the proposal

 

[freetrader]

Thanks for the explanation. Yes, that would work unless an increasing majority wants to abort (e.g. late-stage bug discovered). That would necessitate a different abort strategy than increasing your threshold, but I think that's a peripheral consideration

 

[Tomas van der Wansem]

AFAIK to propose a buip that could voted you need to be a member or find member who's going to sponsor it

It seems to be well received, so it might be nice to add a number. Can someone help with that? Should I PR the proposal with a number given?

 

[sickpig]

@Tomas van der Wansem

There's no assign number just pick the first free one, should be 56. If any conflicts arise @solex will take care of fixing it.

It would be great if you could open a PR at https://github.com/BitcoinUnlimited/BUIP to add this.

And I agree your proposal seems to be well received. wonder if a BU member could state an official endorsement so that you could add the sponsorship to the PR

 

[Zangelbert Bingledack]

I officially endorse this BUIP as I think it is worth being put to a vote (my own vote remains undecided).

 

[Tomas van der Wansem]

Thank you. I have added a pull request for BUIP056

 

[freetrader]

Could you please edit the title of this thread to prepend the 'BUIP056' - makes it easier to find when looking at the threads list in this forum. Thanks!

 

[sickpig]

Thank you. I have added a pull request for BUIP056

I've commented on the PR, thanks for your effort!

 

[solex]

I have added BUIP056 to the index, and updated it to recognise @Zangelbert Bingledack's sponsorship.

 

[Tomas van der Wansem]

Thanks @solex, it's not yet here? https://github.com/BitcoinUnlimited/BUIP

I have added a pull request there.

 

[sickpig]

@Tomas van der Wansem
@solex was referring to the index hs is curating in this section of the forum:

https://bitco.in/forum/threads/buip-index.1414/unread

(initially, bitco.in was the unique repo where we stored BUIPs, along the way we added the github repo. recently we even integrated a voting system for BUIPs in our website.)

(just merged your PR in the BUIP GH repo)

 

[Jihan]

For the first time when the block size needs to break through the 1MB limit, please pay attention to the re-org risk as I mentioned in my reply to BUIP055. After that, the block size is not a hard limit or the hard limit is very high, and the effective block size is governed by EC, then this proposal will work well. It will be a very specific and determined mechanism to manage the settings and its changes of EC.

The threshold: I think we should just hard code a 75% into it, and not letting miners to configure this number. Anyway if miners want, they can change the code of their nodes to change this threshold, but given a specific voting process, a specific threshold should be defined before it is started. We should not encourage the difference of opinion among miners about this threshold. If they do have very strong different opinions, they can always speak out by running different clients or change the code themselves. As a host or owner of such BUIP, they should take responsibility to find the best possible threshold. A proposed threshold may be criticized and rejected, but it should always be proposed.

 

[painlord2k]

@Jihan, I understand your worries, but I think you are asking for the wrong solution: BU centrally hard coding a specific policy pertaining only to the miners.

BU hard coding a 75% threshold to activate the fork is wrong as much as Blockstream coding a 95% threshold to activate SegWit or a 75% discount to the witness data. Just magic numbers inserted because someone wanted it and he had his voice heard where others could not be heard for whatever reason.

The best things BU could do is to give the miners the tools to communicate their preferences and coordinate the increase as best as possible. As I understand it, BU doesn't want to decide over thresholds or other magic numbers because it is the miner's job to decide these numbers. Their responsibility, their risk and their reward.

You do not swap Core with Unlimited, you swap Core with miners. Swap a reference implementation (Core) with a protocol (Bitcoin).
It could be messy, but freedom often is. But, as much freedom is messy, the alternative is a dictatorship and they are rarely cleaner and neater. Bitcoin today is a sorry example of this.

What will happen if BU code a 75% threshold and 66% want to fork ASAP?
Maybe they are willing to endure the risk of a reorganization to get the rewards of an earlier increase in capacity. Maybe you will be willing to take such a risk the next month or two. Who knows the future for sure? More important, who is BU to decide for the miners?

The same is true for hard coding an anti-reorganization rule in BU. I suggest BU developers allow a configurable setting & signal in the blocks. The miner will signal if he wants to accept, as the forking block, only a block larger than the previous maximum (To clearly and cleanly move from the current consensus to the new). This would allow a minority HF too, if the miners decide is their only option to break the stalemate.

I suggest to trust with the branch with more PoW as much as possible. If the majority support bigger blocks, and it is large enough, it will be all over in a matter of hours at worst. Because if the majority risk to lose some block reward after the fork, the minority is sure to lose every block reward after the fork.
Just give the minority the time to switch sides when the majority is ready to move.

 

[Tomas van der Wansem]

@Jihan

Thank you for your response. I don't think the reasoning for a 75% threshold is convincing. If that is the threshold of a proposal, you risk miners not getting on board because they think 75% is too low.

I would like to prevent that - for example - 90% agrees but doesn't signal because of the chosen threshold.

This proposal shows that there is no need to agree on the threshold to coordinate the change. Therefore I do not really understand the benefit of making it part of an increase proposal.

As for the reorg risk, I would think this is no longer a problem with enough threshold. For certainty we could add a rule for it, though it is not easy to define something like that without too much loss of generality,

The tricky part is that this proposal (and most similar proposals) do not in itself enforce following the main chain. Miners and nodes that split off because they have not set or implemented FE, are still technically following the rules as defined in this spec. Their blocks aren't made invalid by this proposal.

To clarify: This proposal does not state that once 75% votes for 2mb with a 75% threshold, the limit is now 2mb. Instead it states that the limit for these 75% is now 2mb. The 25% splitting of is still following the rules.