CHIP-2025-03 Faster Blocks for Bitcoin Cash

[bitcoincashautist]

CHIP-2025-03 Faster Blocks for Bitcoin Cash

Faster Blocks for Us - Fab(u)lous!

The CHIP proposes reducing Bitcoin Cash’s block target time from 10 minutes to 1 minute to enhance transaction speed, reliability, and user experience. It delivers faster confirmations, with 95% of single-confirmation transactions clearing in under 3 minutes, compared to 25% exceeding 14 minutes today. By shortening confirmation times, it reduces risks for zero-confirmation (0-conf) transactions, promoting wider 0-conf adoption. It improves multi-confirmation reliability, providing frequent progress updates and lower completion time variance, with a 60-minute target (60 x 1-minute confirmations) completing in under 73 minutes 95% of the time, versus a 20% chance of exceeding 79 minutes for a 60-minute target (6 x 10-minute confirmations) today. Modern networking ensures orphan rates stay below a tolerable 2%, maintaining scalability, security, and decentralization. The proposal introduces a “tick” system to measure block height with fine-grained units, enabling easy future target block time adjustments while ensuring forward compatibility with consensus rules, such as the original 21M halving schedule, transaction locktimes, difficulty adjustment algorithm, and adaptive blocksize limit algorithm. This upgrade establishes Bitcoin Cash as a faster, more competitive blockchain for both cash and DeFi applications.

[above introduction was edited by moderator at request of poster to match current CHIP introduction as of 2026-09-28]

ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab

This is a starting point, only wrote Motivation & Benefits, and a list of technical challenges we’d need to address if we really want this.
Technical challenges are plenty, even if “just” changing block time target to 2 minutes (no Tailstorm, weak blocks, infra blocks, etc.).

I think the key technical challenge is to future-proof it: what if we want to change again (due to further advancements in block propagation) or upgrade to something like Tailstorm?
If we’re going to break things - let’s break them only once but without locking ourselves out of future upgrades.

It should be possible to abstract the block time, by starting to use “blockchain time” in seconds, rather than raw height. Right now we’d get blockchain time by simply multiplying height with 600. Imagine if nLocktime worked with this rather than raw height. Then we could seamlessly change blocktime target and consenus would correctly recompute it when evaluating locktimes, e.g., blockchain_time = fork_height * 600 + (height - fork_height) * 120, without breaking any contracts.

Also, it should be possible to add somewhere a hash dedicated for SPV that would skip over N headers so clients wouldn’t need to keep whole header chain, they could keep only skip hashes - and fill in header hashes where necessary. Or, a super merkle tree like mentioned here.

These individual technical solutions could be split off to individual CHIPs, but they’d only make sense if the over-arching goal was to make block time parameter something that’s “easy” to change.

[architect]

This is a fab(u)lous starting point, pun intended.

It would be good to also summarize the reasons why the 10min blocktime was implemented in the first place, what advancements made it so that it could be reduced now, and why 2min would be the way to go now. Why not 1min or 5min instead?

For example, you could review and revise the following summaries and their placeholder numbers:

Satoshi chose a 10min blocktime for bitcoin to balance transaction speed, security, and decentralization. A longer blocktime reduces the risk of orphaned blocks, ensuring network stability and consensus. The 10min blocktime also helps to maintain a predictable and relatively stable difficulty adjustment recalibrations to keep the blocktime relatively consistent. Shorter block times could lead to more chain reorganizations, compromising security. The 10min blocktime supports decentralization by preventing large miners from dominating the network. It allows smaller miners to compete more fairly by reducing the advantage of those with more computational power. Overall, the 10min blocktime has contributed to bitcoin’s stability and scalability.

Reducing the blocktime almost 2 decades later is more feasible because of faster network propagation, improved mining hardware, and more efficient difficulty adjustments. In the past, the limitations of network speed, mining hardware, and the difficulty adjustment mechanism made it difficult to reduce the blocktime without risking instability and security issues. These technological improvements now make the faster blocks more viable while maintaining BCH’s core values of decentralization, security, and scalability.

A 1min or 2min blocktime could increase the risk of orphaned blocks, where multiple blocks are discovered simultaneously, leading to inefficiencies. The shorter blocktime could increase the frequency of chain reorganizations, undermining transaction finality. The network security could be compromised by reducing the time available for block validation. The faster blocks could also favour larger miners with more powerful hardware, potentially centralizing the network. For a small miner, the potential of finding 10x 1min blocks in a given timeframe is likely lower than the potential of finding 1x 10min block. There could be less time for blocks to propagate across the network, raising the risk of forks and network inconsistencies. With too short intervals, the chances of double-spending or other attacks could grow due to insufficient time for verification. The network would need more frequent difficulty adjustments, which could be inefficient or hard to implement. In summary, while faster blocks might speed up transactions, they could undermine BCH’s security, decentralization, and stability, making 2.5min to 5min a safer range.

Note that the numbers above are without proper research. They are just placeholders for the argument’s sake - we should describe why X is too fast whereas Z is too slow, thus making Y such that X < Y < Z the ideal choice.

[BitcoinCashPodcast]

I gotta admit, on the surface I am strongly against the idea of changing the 10 minute blocktime. It’s been more than serviceable, is well understood as a key aspect of “Bitcoin” & so fiddling with it seems like a high risk endeavour that could seriously impact the legitimacy claim of BCH to “the real Bitcoin” legacy (which is both financially, culturally & emotionally important). Be prepared for a lot of arguments like “Oh you’re gonna change the blocktime, next you’ll change the 21 million cap!” And to be fair, that isn’t a terrible argument.

That said, the more I think about it, the more I’m willing to consider the idea. BCH is really doing a good job of establishing its own contrasting brand to BTC & we’ve done enough changes with CashTokens that I doubt 2 minute blocks would undermine our claim to legitimacy in the public eye sufficiently (we have the genesis block, SHA256, PoW, 21m - which are the key elements). If it could be sufficiently demonstrated that the benefits of lower block times would be substantial (especially with consideration of impacts on the mining ecosystem), then we should at least consider it. 10 minutes isn’t perfect just magically. We already have a better DAA, a better blocksize algo - why not have a better blocktime too? The reality is that BCH is in the minority/underdog position, which means the onus is on us to change up the status quo to get an edge. So from that perspective, blocksize changes is something we should at least consider & discuss.

Even if it doesn’t lead to a changed blocksize, I think the research & investigation into this problem will prove very fruitful and perhaps lead to other upgrades or knowledge as a result. So I look forward to following this thread.

[tom]

It should be possible to abstract the block time, by starting to use “blockchain time” in seconds, rather than raw height. Right now we’d get blockchain time by simply multiplying height with 600.

You’re not building an argument. You’re just stating an opinion that has no justification.

And you follow up with an untrue statement, timestamps are stored in a block header, that is where it comes from. If your argument is that we should improve the architecture of Bitcoin Cash because some people are not using the current architecture (blockheaders), then your argument is false. Those people should improve their code.

[bitcoincashautist]

@tom

You’re not building an argument. You’re just stating an opinion that has no justification.

It’s an abstraction, call it “virtual height” if you will, what matters is that it’s tightly coupled with actual height: right now you’d just calc it as virtual_height = height * 600. This is NOT a timestamp, but it could be interpreted as idealized time since genesis.

It’s like starting to measure height in millimeters rather than decimeters, even if our blocks are decimeter-sized, so we may later change “size” of blocks (on time dimension) while still being able to use the same measure (millimeters) for their height. Does that make sense?

@tom

timestamps are stored in a block header, that is where it comes from.

I know that. And nLocktime isn’t evaluated against it BTW, in timestamp mode it is evaluated against MTP (need 11 timestamps). In height mode it is evaluated against height. The “virtual height” would be a new mode of operation - to be used instead of height, NOT instead of timestamps.

I elaborated on this idea in the CHIP:

Legacy Transaction Locktime and Input Sequence

To ensure backwards compatibility, transaction nLocktime values are evaluated against blockchain_time / 600, normalizing them to the original 10-minute block scale.
This preserves the behavior of existing time-locked transactions as if the block time remained unchanged.
Similarly, the nSequence field for transaction inputs is interpreted under the same 10-minute assumption.

This approach maintains compatibility with existing smart contracts and time-sensitive transactions, leveraging the blockchain time abstraction for consistency.
It also means that legacy locktime, sequence, and related opcodes won’t benefit from increased granularity.
To reap those benefits without breaking legacy contracts, we will need new TX and input fields, and a new set of related opcodes.

New Transaction Locktime and Input Sequence

We propose two additional transaction locktime and input sequence fields, serialized as 8-byte unsigned integers, and where highest 2 bits are used to set mode of operation:

• 0: evaluate against blockchain time
• 1: evaluate against block MTP
• 2: evaluate against block timestamp

This leaves 62 bits for timestamps, which won’t be exhausted until 100 billion years.

[tom]

Thank for the longer explanation, but you really still didn’t build an argument.

What you did was describe an idea, probably how you want something to look if you were designing this afresh. I’ve been a programmer for 3 decades, I fully understand the attraction of designing new stuff.

But in reality, especially when changing existing stuff, you need to limit your changes that are about actual real people. Not just imagined ones.

Nowhere in your chip is any real person shown to have a real problem, nowhere is any real problem solved with any changes. It is all imaginary. A problem that MAY affect unnamed people in the future, in certain situations.
A faster block time that you imagine would have a benefit. It is obviously written from the point of view of a solution searching for a problem.

Thanks for writing it up, though.

[bitcoincashautist]

@tom

A faster block time that you imagine would have a benefit. It is obviously written from the point of view of a solution searching for a problem.

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?

[_minisatoshi]

@bitcoincashautist

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?

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!

[tom]

@bitcoincashautist

Motivation is “let’s have faster blocks”

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.

[bitcoincashautist]

@tom

True central planning logic.

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.

@tom

Not looking at secondary effects and not even acknowledging there are 3rd level effects.

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?”.

[BitcoinCashPodcast]

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.

[ShadowOfHarbringer]

@BitcoinCashPodcast

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.

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.

[ShadowOfHarbringer]

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.

[kanat]

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.

[bitcoincashautist]

@kanat

We have already seen how changes to the protocol split the community several times

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.

@kanat

The idea of BCH for me is zero conf.

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.

@kanat

If we move to faster blocks, the whole philosophy of instant, peer-to-peer cash might be replaced with just “wait 2 minutes.”

Then why are some LTC-ers pushing for 0-conf, too?

@kanat

Faster blocks may sound good, but it can break network stability and make BCH more centralized (higher orphan rate).

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

@kanat

BCH is about simple money not overengineering.

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.

@kanat

If BCH goes to 2-minute blocks, it might win some short-term attention but lose its “soul” in the process.

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?

@kanat

It’s not worth risking the whole project just to make confirmations few minutes faster.

What makes you think it would be risking the whole project?

@kanat

If this change creates another split or weakens the community’s unity, BCH will never recover.

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.

[bitcoincashautist]

@BitcoinCashPodcast

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

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.

[lucasmcducas]

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.

[tom]

@ShadowOfHarbringer

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

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.

[bitcoincashautist]

@lucasmcducas

It’s effect on stability and orphan rate has already been debunked.

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.

[ShadowOfHarbringer]

@bitcoincashautist

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.

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.