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

[Tomas van der Wansem]

EDITED; first message was not good.

That said, it is possible to prevent a reorg.

For any given node, let A and B be valid blocks with conditions

• Both A and B are validated with max_block_size > current_limit given the rules above
• A has any ancestor block with size > current_limit
• B has no such ancestor
• B is not an ancestor of A

then B must be rejected.

I wrote I am not in favour, but I think this is a good idea. For high thresholds it might not be needed but the BUIP also allows lower thresholds for which it is needed.

 

[Christoph Bergmann]

Thank you for this proposal! I would like it very much to have such options in my BU client. It could help to prevent following accidently the wrong chain and can help the miners to get feedback.

Like in BUIP55 I agree with @Jihan that it should react on the established coordination mechanism for consensus change and that the implementation of the reorg-protection should be part of it.

However I doubt that hardcoding a threshold like 75% is a good idea. There might come the day when 66% or so need to split to survive. Hardcoded numbers might make this more difficult. Also such a number could make it harder to test how the fork plays out ...

 

[Zangelbert Bingledack]

I'm not sure I buy the argument that reorg protection isn't needed if the threshold is high enough. Minority chain survival should not be on the table even as a wild protest move. I think "voting with CPU power" for a new rule entails taking every measure to totally squash any remaining chain that wants to stick to the old rules (unless they change PoW).

 

[Tomas van der Wansem]

Ok. I agree. Unless people have other objections I will add Jihan's anti-reorg proposal, like described in #21 to the BUIP

 

[painlord2k]

The problem is reorg protection prevent the node from following the branch with most PoW.
It should be avoided if possible.

A 75% fork has around 16% chance to be overcome after the first big block or a second block is mined on top of it before the minority is able to catch up.

The chances for the minority fork to be able to cause a reorganization are around 16% during the first 30 minutes, 3% after an hour, 0.09% after two hours, 0.0027% after 4 hours.

Compared with the bounty transaction greater than 1 MB and the fee in the mempool, the risks incurred by the first to mine a 8 MB block are totally irrelevant.

An 8 MB block would gather 16 BTC in fee today (at least, using the lowest fee entering the block).
A +100% profit with a 84% success rate.
I would try it without second thoughts.
[doublepost=1495048311][/doublepost]

EDITED; first message was not good.

That said, it is possible to prevent a reorg.

....

I wrote I am not in favor, but I think this is a good idea. For high thresholds, it might not be needed but the BUIP also allows lower thresholds for which it is needed.

I hope the block will signal an anti-reorg rule and BU will make the rule active by default for <=75% thresholds, but leaving the node manager able to switch it off.

 

[Tomas van der Wansem]

> I hope the block will signal an anti-reorg rule and BU will make the rule active by default for <=75% thresholds, but leaving the node manager able to switch it off.

I am not sure I understand this reasoning. If we turn it off for >75%, just because the risk there is minimal, we could just as well leave it in because the risk there is minimal, right?

It doesn't effect anybody *unless* a big reorg would otherwise happen.

The thing is, that the (small) risk of a reorg with >=75% doesn't come from the 25% being lucky, it comes from miners changing their mind, or false flagging...

 

[painlord2k]

"I am not sure I understand this reasoning. If we turn it off for >75%, just because the risk there is minimal, we could just as well leave it in because the risk there is minimal, right? "

You are right. Fundamentally, we are bikeshedding around a number.
The protection can be optional, but active by default. Miner's choice to turn it off.
I suppose we can agree it MUST be signalled (in the Coinbase) if active.

The risk of miners false flagging, changing their mind or losing majority status is an unavoidable risk.
We should not care about that.

We give the miners the tools to follow the most PoW branch with the AD parameter if it exceed the excessive block size.
We could just use the same AD setting to allow the miners to reorg only after the most PoW branch is ahead of AD "n" blocks with the setting decided by the miners. They would be free to set 0,4, 6, 100000 and change them if they want for whatever reason. Every miner can then signal their commitment to the branch they are mining at the time.

 

[Tomas van der Wansem]

> We could just use the same AD setting to allow the miners to reorg only after the most PoW branch is ahead of AD "n" blocks with the setting decided by the miners. They would be free to set 0,4, 6, 100000 and change them if they want for whatever reason.

Hmm. First of all BUIP056 isn't tight to the blocksize being "elastic" or "emergent". If BU adopts this, I was planning to propose a BIP for Core's MAX_BLOCK_WEIGHT update scheduling, which would be compatible with BUIP056. This would have to include BU's sigop/tx limits, but not necessarily AD.

I am also not that sure whether this amount of configurability may be excessive. I see why miners and nodes would want to use different future block sizes and different threshold, but if everyone chooses their own "reorg-AD", it will become very hard for them to reason about risks.

My preference would be, either to put it in or to leave it out to keep things simple.

Note that miners and nodes *always* have precise control by means of the "invalidateblock" RPC.

META: I can only sometimes use "Quote" and no manual quote formatting?

 

[painlord2k]

Core is not the center of Bitcoin. They don't matter at all.
Talk with the Parity, Bcoin, etc. Ignore Core.
Treat them like the natural disaster they are: look what they do, how this impact you or others but don't talk to them. Would you talk to a cyclone? A earthquake? a tsunami? I would not, mainly because it is a waste of time and signal weakness.

Don't give pearls to porks and holy things to dogs. Because the first will trample on them and the second will turn against you.
It is in the Gospel and it is a sound advice useful everywhere, everytime.

Let Core burn and not waste time with BIPs. Let them do whatever they want. They have 100 or 400 developers. The best, most brilliant, in the world. They can manage their own development, if they want.



The EC is an iterative process.
1) Miners signal their preferences so others can see them.
2) Miners see the others preferences and act (changing or not theirs) in response.

You should provide them with reasonable defaults, but leave them with the ability to change these.
If you prefer, you can make the settings available only on command line so "Average Joe Sixpack" don't mess up

The most easy way is the first miners to set reasonable conditions to HF is followed by everyone else.

EG.
Via BTC and a bunch of others signal for FE8@66% but they just have 62%.
AntPool signal FE8@75% and it has 15%.

They look at each

All FE8@66% start signalling @75% and they get the quorum needed to activate the HF they want.
Or AntPool change to 66% because it knows they would have the 75% they want anyway looking at the numbers. And they fork earlier.

 

[Tomas van der Wansem]

@painlord2k

I am sorry, I am not really on board with this Core=evil rhetoric not because I disagree, but because I don't think it is fruitful.

More importantly, in a heterogeneous environment key to innovation is decoupling. Every proposal should touch on as little other proposals as possible. This is why for example BIP140 is better than SegWit.

I am not against EC, but as it stands BUIP056 is not coupled to emergent consensus at all; it can serve EC, but it can equally serve those that have a more "strict" idea on the block size parameter.

Therefore, I think relying on EC for reorg protection has more drawbacks than advantages.

 

[painlord2k]

Maybe the answer is BUIP056 should just concern itself only with the activation of the fork.

The protection from reorganization should be something independent from it.

So the development on one don't slow the development of the other and make easier to develop something more general purpose and not tailored to some specific use case.

 

[Zangelbert Bingledack]

@Tomas van der Wansem Quoting the comment immediately above is disabled on this forum, with the aim of saving space from huge quotes followed by short replies. (I personally don't think it should be this way, as quotes are already compacted into a small expandable window anyway.)

To quote text in the last comment more cleanly, you can copypaste it in, then highlight it, click the [+] icon in the editor, and click "Quote".

 

[Bagatell]

To quote text in the last comment more cleanly, you can copypaste it in, then highlight it, click the [+] icon in the editor, and click "Quote".

or use BBCode Xtra

 

[Jihan]

Hi @Tomas van der Wansem , I think I can understand and accept that as the host of a proposal, you refuse to give any advice on the threshold and force miners to find and reach consensus among themselves. Especially after EC is governing the block size, a consensus among mining pools about the block size will not be a process lasting years. I think with months level time discussion a consensus can be reached.

But the first time break through 1MB, due to its un-negligible contentiousness, please do add the the "has to be larger than 1MB" rule right at the forking block. It is a very simple fact that we have to realize, breaking 1MB is a totally different event than continuing events to adjust the block size after the hard coded block size has gone.

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

 

[freetrader]

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.

please do add the the "has to be larger than 1MB" rule right at the forking block

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.

Maybe we need the ability to introduce checkpoints dynamically when certain conditions are met.
e.g.

IF the received block would be the tip of the most work chain
    AND the received block is valid
    AND the block's size block is > 1MB
    AND the block has no ancestors > 1MB
    AND the block has at least height X
THEN
    dynamically create a checkpoint from this block.

The existing logic should take care of not re-orging this checkpoint, you would just have to store it persistently.

A basic building block of such anti-reorg would be a feature to dynamically set (and persistently store) checkpoints, and load them from storage when starting.
It would be nice if the conditions could be scripted in some way (without needing to recompile), but that would be going beyond current needs.

EDIT: user 'tulasacra' on Slack proposed a name for an RPC call to add (force) a dynamic checkpoint: "mandateblock" . I think this could be a suitable name, although "addcheckpoint" could also work and might be clearer, since one would need the counterparts "unmandateblock" or "removecheckpoint" to get rid of an unwanted dynamic checkpoint.

EDIT2: based on Slack discussion I thought it would be useful to propose a lightweight form of dynamic checkpoints in a separate BUIP:
https://bitco.in/forum/threads/buipyyy-dynamic-checkpoints.2135/

 

[theZerg]

Hi @Tomas van der Wansem,

Please specify rounding down to the nearest % when calculating percentages.

Also, please clarify what to do in the case where a block is signaling /EBx/ where x >= your FE.
Does that count as a vote for FE?

Thanks!

 

[Tomas van der Wansem]

Hi @theZerg

I can add that new_limit must be larger then current_limit.

> Please specify rounding down to the nearest % when calculating percentages.

Are you sure this not only adds confusion?

As N is an integer, is there any confusion or ambiguity with "at least N% of the blocks"? (implemented as "N * 2016 >= 100 * matched_blocks")

I would think that rounding ambiguities start when rounding..

 

[Tomas van der Wansem]

I see that new_limit must be larger then current_limit is already in.

 

[awemany]

As N is an integer, is there any confusion or ambiguity with "at least N% of the blocks"? (implemented as "N * 2016 >= 100 * matched_blocks")

I would think that rounding ambiguities start when rounding..

I agree with @theZerg, that stuff should be explict. Also the formatting of the percentage and so forth. I feel that this is one area where Core has done a good job with some of their BIPs and we should strive for the same IMO. Writing a BUIP should evoke a feeling of being annoyed by exactness

I also agree with @Jihan that 1MB is somewhat special and although I don't think replay protection is particularly relevant to EC in general, I don't think it hurts in this case, bike-shedding and all that.

 

[Tomas van der Wansem]

Ok. I will add.