Zarathustra
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
BUIP055: (passed) Increase the Block Size Limit at a Fixed Block Height
- Thread starter Peter R
- Start date
And in a 2nd piece of irony, I am just finalizing my plans to literally visit the North Korean border tomorow morning, I shall be on my way in 10 hours time.Zarathustra said:
What are you up to Zarathustra?
xhiggy
Active Member
- Mar 29, 2016
- 124
- 277
BU does not have such a checkpoint. BU gives the asymmetric advantage to the smaller block side, exactly what Jihan is trying to avoid.xhiggy said:
BU isn't intended to "have" or "not have" specific settings or features (defaults as Schelling points are a gray area we can quibble about). Rather it is a tool for implementing settings/features that users are interested in, as options, and will likely add them progressively as user interest and dev time allow.
min_blocksize at a given block height sounds like a good one to add, assuming it's not already in the works.
min_blocksize at a given block height sounds like a good one to add, assuming it's not already in the works.
Zarathustra
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
You are not able to (want to) read simple sentences. How will you ever be able to read BU?
@Jihan thank you for this feedback, I'd like to bring your attention to my observation of events.
This debate is actually about 6 years old, when I learning about bitcoin I did not think it could scale, however when this debate heated up in 2013 I learned I was wrong and by increasing my understanding it lead me to believe we could scale significantly on chain and that block size and disk space are not what limit bitcoin's growth.
The issue now is not whether we can scale or not, but weather we can all come to a consensus independently and override bitcoins decentralized consensus mechanism.
After the first 4 years of debate, this issue came to a head. Gavin made a series of proposal addressing the issue the final one being BIP101 that required 75% mining support before an activation date could be set. It failed miserably - Adam Back called 75% mining support to remove the limit a coup on the hegemony who had blocked previous on chain scaling attempts.
We have spent the last 2 years trying to come to a similar consensus (censorship used as a tool to spread misinformation). Bitcoin users like @jonny1000 say the only way to support a hard fork is to not support it if it is controversial and to wait until there is about 95-98% consensus before showing support, the irony of getting support by not supporting is not lost on me. However he is incredibly hypocritical as he is quite comfortable supporting segwit while it is controversial.
A new solution has just presented it's self, BUIP055 what makes this unique is it changes the dynamic and makes increasing the limit more likely. The new dynamic reverses the chicken and the egg problem of consensus we have struggled with for 6 years, It is more like an evolution, the egg evolves - it doesn't just happen at a point in time:
I'm just going to take a dig at the BU slack.
assuming people have been discussing the ramifications of this BUIP. BU support was growing and it looks like some segwit support had shifted to supporting BU. (looking at https://coin.dance/blocks assuming a 20% variance) that advantage has reverted back to the status quo after the release of this BUIP, I am going to project and say I think it was a results of surprise and it reflects the fact that this idea grew and was presented as opposed to being discussed and debated before being proposed. I take it as a reaction to surprise and uncertainty.
This debate is actually about 6 years old, when I learning about bitcoin I did not think it could scale, however when this debate heated up in 2013 I learned I was wrong and by increasing my understanding it lead me to believe we could scale significantly on chain and that block size and disk space are not what limit bitcoin's growth.
The issue now is not whether we can scale or not, but weather we can all come to a consensus independently and override bitcoins decentralized consensus mechanism.
After the first 4 years of debate, this issue came to a head. Gavin made a series of proposal addressing the issue the final one being BIP101 that required 75% mining support before an activation date could be set. It failed miserably - Adam Back called 75% mining support to remove the limit a coup on the hegemony who had blocked previous on chain scaling attempts.
We have spent the last 2 years trying to come to a similar consensus (censorship used as a tool to spread misinformation). Bitcoin users like @jonny1000 say the only way to support a hard fork is to not support it if it is controversial and to wait until there is about 95-98% consensus before showing support, the irony of getting support by not supporting is not lost on me. However he is incredibly hypocritical as he is quite comfortable supporting segwit while it is controversial.
A new solution has just presented it's self, BUIP055 what makes this unique is it changes the dynamic and makes increasing the limit more likely. The new dynamic reverses the chicken and the egg problem of consensus we have struggled with for 6 years, It is more like an evolution, the egg evolves - it doesn't just happen at a point in time:
- after block height 488888 miners agree to accept a >1MB block.
- this creates uncertainty - for those who used bitcoin they need to mitigate that uncertainty.
- they do this by preparing to accept a block that is >1MB
- the network follows the longest chain of valid blocks
(The white paper section 5 a block is valid if it contains valid transactions and a valid PoW.)
- With BUIP055 enabled, you as a miner are saying I will accept a >1MB block and I will take the risk. miners and the network should accept that risk and prepare to accommodate that probability.
- if BUIP055 has a only 40% support there is no incentive to make a >1MB block, you just acept the risk of mining on top of one.
- Other miners also want to mitigate risk - they should prepare to accept a >1MB block. it is irresponsible to not do this without a valid reason or to push segwit.
- if a >1MB block is mined it will be built on or it won't - miners have to put something at risk.
- You don't need to build on it but the network needs to prepare for that eventuality and drawing a hard line in the sand @ Block height 488888 creates a shelling point.
I'm just going to take a dig at the BU slack.
assuming people have been discussing the ramifications of this BUIP. BU support was growing and it looks like some segwit support had shifted to supporting BU. (looking at https://coin.dance/blocks assuming a 20% variance) that advantage has reverted back to the status quo after the release of this BUIP, I am going to project and say I think it was a results of surprise and it reflects the fact that this idea grew and was presented as opposed to being discussed and debated before being proposed. I take it as a reaction to surprise and uncertainty.
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
bitPico
New Member
- Mar 7, 2017
- 21
- 5
Jihan,
Thanks for your efforts in upholding what we've explained to the BU developers. The only proper way to change a consensus variable is through BIP9/BIP135.
Finally after 3 months of telling BU Slack that Coinbase signaling is wrong (ignorant) it's refreshing to see you backing our proposal to stick to regular well known and tested consensus change methods through BIP9 and furthermore with BIP135.
Keep up the great work!
Thanks for your efforts in upholding what we've explained to the BU developers. The only proper way to change a consensus variable is through BIP9/BIP135.
Finally after 3 months of telling BU Slack that Coinbase signaling is wrong (ignorant) it's refreshing to see you backing our proposal to stick to regular well known and tested consensus change methods through BIP9 and furthermore with BIP135.
Keep up the great work!
No. Showing support is fine. I show support for BIP100 all the time. The issue is enforcing the new rules before consensus, not showing support
Zarathustra
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
Yes, it has been called 'perverted Nakamoto consensus'. And then the bitcoin user @jonny1000 went to reddit and accused us of calling him 'a pervert'. These are the slander tactics of users like @jonny1000.
Christoph Bergmann
Active Member
Thanks for proposing this, Peter! A simple, working, clear Blocksize increase is what we need, and if properly done, it should easily find large consensus in the ecosystem.
I'm all for what @Jihan says: If there is an established method for consensus changes, use this, and it seems like a powerful idea to make it a consensus rule that at a given, variable blockheight the size must be > 1MB.
BitPay tweeted something about 8/2, 8MB hard, 2MB softlimit. Maybe this is the way to go?
Imho it is important to develop simple patches for Core. Let' them keep "Core quality" and SegWit ready to go, but give them the option to agree with the new limit.
I'm all for what @Jihan says: If there is an established method for consensus changes, use this, and it seems like a powerful idea to make it a consensus rule that at a given, variable blockheight the size must be > 1MB.
BitPay tweeted something about 8/2, 8MB hard, 2MB softlimit. Maybe this is the way to go?
Imho it is important to develop simple patches for Core. Let' them keep "Core quality" and SegWit ready to go, but give them the option to agree with the new limit.
1. Segwit is a softfork
2. Segwit does have a 95% miner threshold
3. Segwit does not have the asymmetric disadvantage
Last edited:
No. As I explained, what I call "strong consensus" and you call "perverted extreme consensus" is required in order for the chain to survive, only if the new chain can be wiped out, if it loses the PoW lead.
As I categorically explained here:
This is ironically now almost identical to what Jihan was saying. A block should be required to be MORE than 1MB. Or as Jihan put it:
If this occurs, we agree now, "strong consensus" is no longer required to ensure the chain survives.
Last edited:
- Aug 29, 2015
- 536
- 2,597
I like this proposal.
I'd like to suggest a tweak though. How about changing the default activation date to Aug 1st?
This corresponds to the flag day for UASF activation.
This would offer a nice decision point, a clear point for these two options to go head-to-head.
The UASF promoters are pushing people to make a decision Aug 1st. Why not take advantage of this opportunity to offer a clear alternative?
I'd like to suggest a tweak though. How about changing the default activation date to Aug 1st?
This corresponds to the flag day for UASF activation.
This would offer a nice decision point, a clear point for these two options to go head-to-head.
The UASF promoters are pushing people to make a decision Aug 1st. Why not take advantage of this opportunity to offer a clear alternative?
@Peter R
I am concerned about the parsing of this field by other software:
EB<new_limit_MB>@<activation_height>...)
What about using FE "future EB" instead? This would be consistent with BUIP001's "FGS" and with BUIP056
I am concerned about the parsing of this field by other software:
EB<new_limit_MB>@<activation_height>...)
What about using FE "future EB" instead? This would be consistent with BUIP001's "FGS" and with BUIP056
Last edited:
@theZerg: yeah, I keep going back-and-forth here. I prefer EB so that people don't need to learn what FE means. However, I understand your point. It was actually FE until @go1111111 convinced me to go back to EB.
Ok, so after some thought and pondering on the proposal, I think I like this. I especially like that activation at blockheight is just as Satoshi intended For that reason, I also like it just a tad more than BUIP056.
However, BU is about choice, so I guess having both ways to signal would be fine, as well.
For that reason, I also like it just a tad more than BUIP056.However, BU is about choice, so I guess having both ways to signal would be fine, as well.
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."