BUIP055: (passed) Increase the Block Size Limit at a Fixed Block Height
- Thread starter Peter R
- Start date
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.
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?
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
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?
@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.
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
Well-Known Member
- Sep 29, 2015
- 2,424
- 6,410
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!
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!
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.
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.