CHIP-2025-03 Faster Blocks for Bitcoin Cash

#7

Motivation is “let’s have faster blocks”, and from there we work out the technical challenges needed to have that. Solutions will be result of trying to work out the technical problems (and cost on the ecosystem) of having faster blocks.

Why this height abstraction? In past discussions I’ve seen arguments along the lines of: “2 minutes is not good enough, we’d want 10s, but we can’t have that now due to tech limits, and if we break stuff for 2 minutes now, then we’d have to break it once more for 10 seconds if it should ever become technically feasible to go down to 10s”

That is indeed a concern, what if later we want to drop to 1-min, then some breakthrough is found allowing us to go to 10s? How many times do we ship a breaking change? Which is why I’m now investigating: what if we could break it only once - set us up so we can later change it again without further breakage?

6 Likes
#8

Best part of this CHIP in my opinion.

10 minutes was picked at the time as a good balance, but also, the number itself is arbitrary, maybe 9 minutes was better or 12 minutes or 7 minutes, but those weren’t good round numbers. Just because it started at 10 minutes 15 years ago doesn’t mean we always need to be 10 minutes. And if we can explore a way to make any future block time changes easy, all the better!

6 Likes
#9

True central planning logic. Not looking at secondary effects and not even acknowledging there are 3rd level effects. Go read “economics in one lesson”, you’ll notice that all bad decisions are based on the same tenet.

The true way to make this problem go away is by making Bitcoin Cash usable as cash and used by millions every day to buy goods and services. That enables zero conf as a proper solution for most.
If you don’t know how to get there, then ask those of us that do and work on solutions that help people buy goods and services. With the goal to make the end users’ experience at least as good as using your local bank.

Shortcuts like your proposal do the opposite, they get in the way and disrupt the ecosystem for those building while having at best questionable claims on usefulness.

Doing protocol changes is only useful if you do that in line of actually building end-user visible products.

#10

Original 10-minute block time is the result of Satoshi’s “central planning”, because he didn’t consult with anyone else about that parameter for the first release, or do a statistical analysis of what it means for users (50% chance of more than 17 minutes wait). If he did, maybe he’d have chosen 2 minutes, who knows.

If we would tweak his plan, it would be a less centralized decision, because if we’d do the change then we’d do it because most people would want and support the change.

We will look into those as CHIP progresses, and we have looked at it when discussing this many times on various channels, it just hasn’t been captured by the CHIP yet.

If we don’t want the change, why would we even bother to look further when we could simply dismiss it as not wanted? So, first step is to determine “do we even want this change?”. Next step is to determine “could we mess up something if we would go with this change?”.

3 Likes
#11

I am constantly surprised at how the BCH community, in general full of intelligent clear thinkers, is totally unable to separate the concept of considering an idea while undergoing further research and discussion from “I am trying to jam this into BCH right now & you need to hate on it with every objection you can, including the self-evident lack of comprehensive evidence”.

Particularly with CHIP proposals.

Absolutely crazy. It’s just an idea, yes there will be more research, yes there will be more discussion, yes it’s just hypotheticals of would this be good or not and maybe by thinking it over we get to this solution, or a better one, or no change. Maybe we need a specific word or label or something to adjust this perception because it’s apparently too difficult for many people by default.

4 Likes
#12

Not really that crazy, when you think about how decentralization works.

When a system, such as BCH is decentralized:

  • There is no King/Linus Torvalds to tell you whether an idea will be hard-considered for inclusion or not
  • There is nobody to tell you whether any discussion about a proposal is actually a serious consideration or just discussing for fun / for the sake of discussion and mind food
  • Various ideas get discussed and nowhere there is a sign that says “NOTE: This (dangerous) idea is not being considered for inclusion, it is just being discussed for fun”
  • There is constant endless flux of people interacting and ideas proposed randomly with no clear direction and statement about intention of these
  • There is no strict hierarchy in the BCH community, so at times it seems like only because somebody (usually prominent) is proposing something, it could mean that his idea can get implemented
  • The Overton Window on every proposed idea keeps moving on itself from one edge to another due to natural factors, even without external manipulation

So naturally, because of the above:

  • Many people who have (understandable) difficulties discerning what is going on in all of this are acting up/getting worked up because they start to feel that the “Bitcoin” that they worked on for years would be destroyed/impaired by a specific idea
  • There being no King/central planner also means that these reactions will tend to repeat over and over and over again because there is nobody that would just say “STOP, this idea is dumb and will not make it it”

That being said, I am not criticizing this mode of operation, I am just trying to explain where do all of these issues come from.

The issues we are having are/should be completely normal in a (theorized) decentralized system with no central governance.

1 Like
#13

Basically TL;DR of the above is:

Decentralization is super messy. Without a king, people will keep endlessly arguing about every different idea, some will treat it seriously, some will treat it just like entertainment.

1 Like
#14

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.

#15

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.

6 Likes
#16

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.

2 Likes
#17

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.

3 Likes
#18

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.

#19

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.

1 Like
#20

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.

#21

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

3 Likes
#22

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.

#23

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

#24

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.

1 Like
#25

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.

1 Like
#26

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.