BUIP055: (passed) Increase the Block Size Limit at a Fixed Block Height

[JAFO]

I support this BUIP, but I would prefur BIP100 style voting rather then a fixed block height.

 

[RegisteredUser]

I love this proposal and I think Re-org protection is a great addition. My only issue being October is too far away. This needs to be fast-tracked. The mempool will be even greater by then, that is, if people are still using Bitcoin.

 

[jonny1000]

Based on discussion and feedback from miners, I have added re-org protection to BUIP055. Please refer to the two new sections "Re-org Protection" and "Rationale for Re-org Protection."

At last....

That was a painful 18 months. Given the comments, I am not sure you understand the economic/financial implications of wipeout, but we are getting there

I don't think you should literally have a minimum blocksize, I think people only say that as an illustration.

Why make the rule only temporary?

 

[AdrianX]

Once the network upgrade is complete and the small-block chain is extinguished (or no longer a threat of catching up), this temporary rule can be removed.

Just drawing on past experiences the last time I saw someone say something similar to this it became very difficult to remove when it was no longer needed.

@Peter R Can we add a magic number, a block high distance after the fork to deactivate it. Make it a week, a month , 6 months, but I think it would be prudent to take the effort to make a temporary rule terminate - and not leave it to anyone to remove - those changing it send a signal of non cooperation, rather than inaction resulting in inaction.

Could we make that code a modular feature so it could be reused in future temporary BUIPs possible make it a BUIP in its own write to remove temporary rules at X block distance?

 

[torusJKL]

@Peter R I like the re-org protection but I wonder if it could be abused.

Could a scenario exist where a miner would increase the size of the block by a little with every block he mines and protect his block from others that would have orphaned his block in the current network (e.g. found at the same time).

If such a scenario is possible would it be an option to add a grace period in which the bigger block chain could be re-orged? Something like an AD but for re-orgs.

 

[Norway]

Just want to say thank you @Peter R for this BUIP.

BU is very much about helping miners to coordinate their max blocksize. Today, all miners can do is signalling what they are currently doing (with EB), but what's needed is to say what you are going to do and when.

I see it like a turn signal for a car. There is no point of signalling while you turn the car. You have to signal before you turn so other cars can adapt accordingly.

I'm actually not sure if we really need the first EB parameter. If you are an active miner making money, you are compatible with the current block size limits on the system. But it's not a big issue to me weather to keep it or not.

I support this BUIP. Time to break out that private key and vote!

 

[painlord2k]

If there must be a temporary soft fork to prevent chain reorganization, there should be a default time to remove it. If it is a transitory rule, make it immediately transitory.

Make it last 2014 / 4028 / 20140 blocks and then it automatically go away.
Allow people to extend it or end it if they choose so.

 

[Peter R]

Updated default forking height to 484,784 and default block size limit to 2 MB.