I am not technical expert, but I am against this idea. We have already seen how changes to the protocol split the community several times (BSV, eCash). Faster blocks may sound good, but it can break network stability and make BCH more centralized (higher orphan rate). It’s not worth risking the whole project just to make confirmations few minutes faster. The idea of BCH for me is zero conf. If we move to faster blocks, the whole philosophy of instant, peer-to-peer cash might be replaced with just “wait 2 minutes.” That’s not the BCH vision. BCH works fine as it is now with zero conf.
If BCH goes to 2-minute blocks, it might win some short-term attention but lose its “soul” in the process. BCH is about simple money not overengineering. The bigger danger is not technical but social discord. If this change creates another split or weakens the community’s unity, BCH will never recover.
We have also seen how changes to the protocol DIDN’T split the community (Introspection opcodes, int64, CashTokens, ABLA, VM limits and big ints) and were a great success.
Nobody is replacing that, 0-conf will still be there and the default mode of operation. Faster confs would just make the fallback to 1-conf more bearable, and could even help people have more confidence in 0-conf.
Then why are some LTC-ers pushing for 0-conf, too?
That is a well understood and well quantifiable problem. If pools have 1s latency and 100Mbit bandwidth then theoretical orphan rates (100% full block) would go up from 0.59% to 0.84%.
Would a 0.25% difference break/destabilize the network and make it more centralized? I think not.
There’s also a little benefit to smaller pools: more frequent blocks means it takes less time for variance to even out (e.g. you’d need to mine for 1 week instead of 1 month to get average of your payouts closer to expected value).
How would 2-minute blocks make it any less simple? It’s still “just money, bro.”
just to make confirmations few minutes faster.
It would make UX feel 20 minutes faster, because you’d almost never experience a wait longer than 13 minutes.
With 10-minute target: you will see 17 minutes or more on every 2nd transaction you make, 30 minutes or more on every 5th transaction you make.
I asked LTC-ers about their wait times, they didn’t complain much: https://x.com/bchautist/status/1825175120815485419
On BCH, I bet many more would recall those annoying 30-min waits. That’s not due to hashrate, it’s just due to how mining/PoW works. BTC has that variance too, they’re just masochists and used to not getting into next block anyway.
20% of BCH blocks had durations shorter or equal than 2 minutes, are they soulless blocks? Nobody seems to complain about those when their TX happens to be in them.
20% of BCH blocks had durations longer or equal to 16 minutes, do those have more soul?
Only about 8% of the blocks had durations of 10±1 minutes, do those have just the right amount of soul?
What makes you think it would be risking the whole project?
Why should it create a split? Network can only split if controversial change is pushed into software. That’s not happening, discussion or a CHIP doesn’t magically create software. Nodes only implement changes that have demonstrated community unity.
Notice also it’s the opposite of dev. worship in centralized projects where community is usually more like “yes, devs announced new fancy XYZ change, this will make our bags pump!!!”
I guess when it is decentralized it all feels more uncertain, unknown, unknowable, chaotic – so people think it’s safer to just resist changes, at least until they get a feel that it’s safe to support some particular change, which is what the CHIP process is all about really. Either it can flip from “everyone fears this” to “everyone wants this”, or it can not.
Shadow elaborated on this well.
It’s effect on stability and orphan rate has already been debunked. Yes there is a risk of social split until there is not, that is true of any upgrade.
Yes, I do agree with this.
On top of that, making an actual proposal (git repo and all) is really already quite far along. Having a written proposal is basically the level of effort people need to do in order to have a wider community feedback. He got that feedback as requested.
Ideas for change basically start with simple discussion, get people to consider the idea and poke holes in it. Maybe reject it. Only when you notice that the idea is not going to be outright rejected by the wider community, then it makes sense to put the time into making that git repo, writing the text and putting in the hours.
This specific idea has been openly and widely rejected many times by a large part of the community. The author’s username indicates he may be tone-deaf to such people saying NO once and not repeating that every time he gets enthusiastic again, while obviously they have not changed their minds. So that is likely why we see these proposals progress to the stage of a chip while they will have a survival rate lower than a fist sized snowball in hell.
The stakeholders politely shutting up is not a helpful idea, it only makes the author keep pushing (he has a history of that) It only makes the wider community think there is actual traction behind a massively destabilizing idea. We’ve seen in the past times when a simple proposal for a disruptive change made miners / stakeholders very upset.
If this was a social group with higher priority on people being happy and less on quality standards, being nice is the right way to go. Bitcoin Cash is not that.
I did some analysis, global pings are below 300 ms and more than 80% VPS providers offer more than 436 Mbit/s uplink and it’s all only going to improve from here.
Even with 3 hops from a mining node to major pools and compact block relay worst case (1.5 * RTT + full block transmission time) - we could have 1-minute blocks stay under 1.99% orphan rate.
More realistic scenario with compact block relay: orphan rates between 0.23% (best case 0.5 * RTT when receiver already has all the TXs) and 0.63% (1.5 * RTT + time to transmit missing 1% of block’s TXs).
With 1-minute target even placing miners on Moon would still be viable (with 2.43%-2.84% orphan rate).
So, I’m changing the proposal from 2 minutes to 1 minute.
Other technical and social challenges are bigger obstacles than orphan rate.
Unfortunately your analysis did not include real-life orphan rates, it is therefore void.
You cannot automatically assume the orphan rates will be within certain range after just studying pings. You need real world data, from working blockchains.
Today I learned that, in December 2019, ZCash changed block time from 2.5min to 75s (spec, info page).
Major exchanges didn’t drop it, it still works, it survived blocksize peak, major pools still mine it.
Maybe our fears (“What will miners do?” “What will exchanges do?”) of making this change are overblown?
Since Compact Block Relay (CBR) (BIP-152) they’ve been (expectedly) so low nobody bothers to report them. You can only find some pre-CBR info which heavily depended on bandwidth so you’ll sometimes find LTC and DOGE folks complaining on old forum posts.
Since then, both LTC and DOGE have implemented CBR and you don’t anymore see the complaints.
Maybe because LTC has 0.02% orphan rate and ZEC has 0.03% (even with 75s block time) (as per ViaBTC)
“You did not throw an apple yourself therefore your calculation of apple’s trajectory is void.”
“Satoshi didn’t analyze a real-life blockchain therefore his analysis in chapter 11. of the whitepaper is void.”
You can’t just hand-wave results of a calculation like that. The same calculation (“Expected Propagation”) predicts Bitcoin propagation times between 0.13s and 0.43s (with orphan rates between 0.02% and 0.07%) - which is close to propagation times reported by bitnodes (0.2 - 0.25s average) and reported orphan rates (ViaBTC: 0.3% for BTC).
Why can’t you? Propagation is a function of latency, bandwidth, number of hops (network topology), and mempool overlaps. That’s it. There’s no some elusive secret cause that’s not captured by the calculation.
For 10s blocks, my calc predicts 3.69% for 99% mempool overlap. ViaBTC reports 3.4% for Nervos chain (which has 10s blocks). I suspect they could do some optimization to more often hit 100% overlap and get closer to 1.24%. (Edit: apparently they use something similar to CBR which they call NC-Max but they also dynamically adjust block times based on orphan rates, tuned to 2.5% target orphan rate).
Well, you can, it’s basic math really.
Real world orphan rates are below 0.05% today (as specified in the CHIP - real data).
For limits, look at just a few variables: ping, bandwidth, block size, hops… These are the only things that can affect orphan rate, outside of potential variables like nefarious miners, but any tools they would have can affect the chain today. No different. This isn’t akin to a change like TailStorm or otherwise where more real world data could be useful.
3.4% actual or limit? Granted, not a 1:1 comparison I imagine since different node distribution/software/otherwise (but also sort of similar since also SHA-256 iirc).
PR submitted to the CHIP with several improvements.
- Introduction section
- Inclusion of demo game
- Clarity of adjustment vs algorithm
- Evaluation of industry competitors
- Inspiration of other proposals
Edit: Don’t have time now, but it would be good to add a visual image of the blocktime game to make the point a bit clearer visually about the larger timeline gaps.
Thanks! I’ll have to make some edits, especially regarding this “A 10-minute blocktime actually produces a median 17-minute wait for users (larger gaps dominate the timeline), which is uncompetitive in the modern electronic payments context.”
After making the game, I realized Rucknium’s introduction of Erlang distribution had led me to a wrong conclusion. Yes, Erlang distribution says there’s a 50:50 chance you “land” in an interval longer than 17 minutes - but when user makes a TX he could “land” anywhere inside that interval and his wait time until the end of interval will still be 10 minutes on average (with 40% chance of exceeding 10 min, and 14% chance of exceeding 20 min).
Erlang affects user’s perception of blockchain slowness, e.g. you pull up explorer it’s been 7 minutes since last block - and you end up waiting 10 more minutes: 17 min total for the block but you only had to wait 10 minutes of that 17.
So, I need to rework Motivation & Benefits sections.
Also need a section dealing with this. People are gonna be very confused about 0 conf or not and blah de blah.
Need a simple, bullet point breakdown of impact on:
- 0 conf ecosystem (none/synergistic)
- People who need 1-3 confs (good, if they don’t care about accumulated PoW)
- People who adjust the 1x10min conf to 10x1min conf (no difference, albeit it accumulates)
- DeFi apps, some of which can accept 0 conf and some which can’t
etc.
https://x.com/TheBCHPodcast/status/1907861271686361516
Plus note that the whitepaper doesn’t specify block time. Because a lot of people are going to be confused/hung up on that.
Just to reinforce the point “specify” – white paper does mention “assuming” a 10 minute block time. Assuming is not the same as specifying.
Sovereign Naan made a 3 video series about 1 minute blocks on BCH as a proposal in September of 2021 - discussing the 1 conf times, faster DAA response, same inflation schedule, concerns about impact on mining - including getting support from Roger Ver & Ryan Giffin. Incredibly prescient.
Haven’t caught up yet but just throwing in 2sats for now:
If the purpose of lowering blocktime is to increase the UX I’d imagine reducing the variance itself would be just as important. Variance would still be common with just a shorter blocktime which would still be a bad UX in the end.
I liked the high-level idea of Bobtail when I first heard of it which was about making blocktimes much more consistent at the intended rate. I think something that addresses blocktime variance as well would make sense to include into any potential blocktime changes since the goal is the same: make blocks more predictable and increase user experience. There is definitely a nice UX when using other chains that generate blocks consistently around the same time.
Going back it seems like BCA likened Tailstorm to a ‘Bobtail 2.0’ so I’m pretty behinde on this stuff now 
But if the end-result of a shorter blocktime is much more consistent blocktime as well then that’s pretty positive imo.
Just for reference:
Bobtail video: https://www.youtube.com/watch?v=GhJqNtYFcBw&list=PLfUWWM-POgQsz0H0uwSVQK5_ISMiW0m98&index=3
Bobtail paper link: Bobtail: Improved Blockchain Security with Low-Variance Mining - NDSS Symposium
My high-level understanding of Bobtail was that it switched blocks to requiring finding multiple valid hashes and it uses X amount of the best ones that miners find for the block, splitting the block reward among those miners. Almost like miners are part of a global pool rather than all-or-nothing, which would have some more consistent payouts for smaller miners.
Will need to read up on Tailstorm, etc.
A shorter blocktime doesn’t change the variation proportionally, but it would change it absolutely - which in this case goes a long way to solving the problem.
Ie the difference between 10 minutes and an outlier of 1 hour (50 minutes) is absolutely extreme, but a difference between 1 minute and an outlier of 6 minutes (5 minutes) is still well below the threshold of 13 minutes to hit user frustration. And with a 10x greater sampling interval, the run of “bad luck” that can string together multiple large-gap slots is also significantly reduced (not proportionally, but in terms of how it feels in absolute terms).
Edit: It’s a good observation to be thinking about how to increase block consistency as well.
Variance would still exist but wouldn’t be bad UX, because variance scales with target time just the same, e.g. right now there’s 13.5% chance of waiting 20+ minutes and 5% chance of waiting 30+ minutes
This will drop to 2 minutes and 3 minutes which is still fast. Outliers of 4+ minutes would be extremely rare, 0.5% of the time
I added a game version where you can set target time and test your confirmation luck against generated durations: Block Interval Game (Simulated)
I did, and I liked it, however it’s really just hiding faster blocks (with the same variance) under the hood + adding uncle branches merging system to alleviate impact of orphans with 12s block time.
Basically it pretends a “pack” of sub-blocks is 1 block so the 1 block (of 10 minutes) seemingly has reduced variance.
With simply reducing to 1-min target time anyone requiring 10-conf (10 minutes target wait) will also see reduced variance.
We could also soft-fork faster blocks, so non-upgraded software would still see 10-min blocks, but with less variance.
I now think we don’t need it, it would add complexity and we can get good enough improvement without it.
You can’t remove variance from a random process, it always exist in the smallest amount of work that gets recognized. You can only bundle these smaller works and pretend the bundle is 1 unit.
More than that though. It allows for lower orphan rates with faster blocks. Also limits benefits of selfish mining.
Imo there is still reason to explore tailstorm, but faster blocks and abstracting block time is the first step.
No, orphans (even though they get merged later) still happen at same rate. The trick is in reducing and socializing reward losses, so miners’ share of revenue still matches their share of hashrate.
This potentially achieves the same, in a much simpler way: A Deterministic Tiebreaker for Bitcoin Block Selection: Enhancing Fairness and Convergence