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

[Norway]

I will vote against this BUIP because miners/pools trusting this lazy mechanism will actually prevent new consensus and new support levels to emerge.

Emergent consensus is made by people, not machines.

EDIT: If all the miners/pools are sheep, they will just stand still. This BUIP is making them passive. I think we can expect pools/miners to pay attention. They will lose money if they don't.

 

[Norway]

I regret I didn't read this proposal earlier and opposed it. Now, the voting is comming to an end. I was too slow. Lesson learned.

 

[Norway]

Sorry! I read this BUIP too quick. It's actually very clever. I'll change my vote now.

 

[AdrianX]

BUIP056 will be developed to manage the block size issue before a fully automatic and mathematical block size governance model is widely accepted. As evidenced in the past years of debate, miners have proved to be very conservative and willing to work with the wider economic community. The rough roadmap of the block size increase for the next few years is below.

looks like #backflip https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/

 

[Tomas van der Wansem]

"backflip"?

 

[AdrianX]

#backflip that's what we can all do when we break the 1MB Nash Equilibrium, its the opposite of the "Flippening"
Congratulations thsi proposal is gaining momentum in the mining community.

.

 

[painlord2k]

I tend to agree with @painlord2k that it might be better to disentangle the 'anti-reorg' from the solely consensus-rule-activation topic of this BUIP.

It seems to me that if there was some value in anti-reorg (and clearly that seems to be the case for some users) then we should look at a generally re-usable mechanism inclusive of, but not strictly tailored only to the 1MB boundary.

The only way in which BU would fork that I am aware of is if it produces a > 1MB block.
So for BU the forking block is by definition the first > 1MB block.

What we want to do is ensure that a chain containing this block is not re-orged unless the operator explicitly overrides a checkpoint created by such a block. This would ensure a lasting fork unless the network (starting with the miners) changes it mind.

The easiest solution, I think, to prevent a reorg of the chain could be simply re-use the AD logic for the minimal blocksize to prevent the reorganization.

When miners decide to increase the blocksize (E.G. 4-->8), they could add a temporary SF where they set a minimum blocksize for the blocks greater than the maximum previous block size.
The number of blocks this SF could last (before being frivolous), could depend on the % of the majority supporting the increase.

In the same way, the miners could set a maximum limit where they decide to accept "defeat" and return to the old consensus.






After the

 

[Tomas van der Wansem]

I think that the reorg protection was mainly for the first upgrade. As it seems that the first increase will be guided by either SegWit2X or UAHF, I think we should remove it from BUIP056.

 

[Zangelbert Bingledack]

Craig raised the question, why doesn't signalling 8MB automatically count as a vote toward the threshold for 4MB, for example?

 

[Tomas van der Wansem]

@Zangelbert Bingledack

It does. Anyone can specify a threshold and a max_block_size.

But the signaled threshold serves as *minimum* threshold and the signaled max_block_size serves as *maximum* max_block_size.

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

Note the "equal to or larger than X".

EDIT

To clarify:

Let's say:
- 70% signals 8mb blocks at 95% threshold.
- 25% signals 4mb blocks at 75% threshold.

Then 4mb is triggered, as 95% signaling 4mb is the lowest common denominator.