CHIP-2025-03 Faster Blocks for Bitcoin Cash

#102

I discussed 1 minute blocks with @joemar_taganna on the Podcast recently.

You can listen to hear his opinion in his own word, but I found it interesting that he didn’t see a strong immediate need for it despite running a large payments/merchant network. This is a pattern I’ve seen in several other people as well.

I’ve really noticed that reactions to the idea of 1 minute blocks tends to fall into two camps:

  • People who see the pain point that 1 minute blocks addresses, and think it’s a really good idea. Maybe people frequently interacting with exchanges, or payment processors that use 1 conf or some amount of confs, or who are heavy in DeFi and see how that plays into things, or who are sick of arguing on social media with people who are shilling alternatives like LTC with lower block times.
  • People who don’t see the pain point, and are more cautious. They don’t think the idea is bad, so much as they can’t see why it’s necessary to change at all or they have confidence in the status quo. It’s interesting that the reservations are around the impacts on mining (which can be addressed with good enough research & consensus building) or the lack of need for this change, rather than any strong proactive reason or aversion to the general concept of changing the block time.

Something for 1 minute blocks advocates to reflect on. Maybe there needs to be a section about this kind of “hesitancy” (not sure if that’s the best word for it).

3 Likes
#103

This is very good point :+1: and you are getting into the main problem here. 1 min block is not needed within BCH wallets, exception is DeFi and AMM in DEXs however with Exchanges , payments processor and even some services like Mullvad etc… its very much needed right now

2 Likes
#104

Hi all,

Great and thoughtful discussion here—it’s great to see the community digging into the merits of faster blocks for improving DeFi UX on BCH, especially around issues like UTXO contention in AMMs, MEV reordering, and variance in recovery times for failed chains. The points on how a deterministic tiebreaker (e.g., from the paper linked) or research like Tailstorm could enhance fairness and convergence are spot-on, and I agree they deserve exploration as simpler alternatives to full block time changes.

High-level, if uncle/orphan rates under Tailstorm for ~10-second blocks end up comparable to current orphan rates (potentially with minimal differences due to its merging mechanics), it could achieve similar benefits to faster blocks with less protocol risk—definitely worth modeling in the context of this CHIP.

To contribute productively, I prototyped a CLI simulator for a covenant-based AMM using “covenant recursion for DeFi without trust.” This demonstrates what’s conceptually achievable today with BCH’s existing VM features (e.g., 2018-re-enabled OP_CAT for concatenation and basic introspection for merkleized state) to enable atomic sequencing without signers or faster blocks, while previewing how proposed 2026 enhancements (e.g., loops via OP_BEGIN/OP_UNTIL and OP_EVAL for modular functions) would make it scalable for high-volume use.

It addresses the core DeFi limitations raised—e.g., concurrent users creating accidental double-spends on public contracts, where only one chain confirms after a block, forcing retries with 10+ minute waits.

The prototype simulates a constant-product AMM where users commit hashed actions (queuing without revealing to prevent front-running), then reveal to process swaps atomically. The covenant merkleizes commits into a fair sequence (appending hashes like the suggested “tagging input” but fully on-chain), then recurses state trustlessly on reveal.

No external server/signing (avoiding the “serial provider” centralization risk, as pointed out), and it keeps AMMs simple with “AnyoneCanSpend”-like openness, per the push: “People want simple AMM… without forcing everybody else to comply.”

Compared to today (where 2018-enabled OP_CAT allows basic versions but requires manual unrolling for sequences, bloating scripts and limiting to ~5-10 commits before size/VM limits), 2026 upgrades make it performant: Loops iterate dynamically (e.g., append 100+ hashes without code repetition, reducing size 5-10x), OP_EVAL modularizes extraction/math (faster execution, no bloat), and deeper introspection strengthens anti-MEV binding. This scales high-volume DeFi without protocol risks—atomic batches resolve contention instantly, complementing 0-conf for “snappier” UX.

Demo run (multi-user with 2 concurrent swaps racing on the same pool; hashes may vary, but logic is reproducible):

> status
Pool: BCH=1000, Tokens=1000, K=1000000
Merkle Root: 0000000000000000000000000000000000000000000000000000000000000000
Pending Commitments: 0

> multi 2
User-1 Committed: Hash ca9f145926c8e58d68cdb92f90d5b8a45da118b81925392f81b599e9f7374aab. New Merkle Root: ea423618fa4c248dcc2eb6c571a1f3841b7c80c9db4e1458c770f7598923e66b
User-2 Committed: Hash 82fac6c59221b850d5dab3832f3f84a075fa8b61bf7bf3bf91f3b09c6a070ab3. New Merkle Root: 64eec1e55a0fe91a539054926c93a110af092df1e246b6cafcc9bf122f5b29ef
User-1 Swap executed: Output 48. New Pool: BCH=1050, Tokens=952
User-1 Merkle Root Updated: fefcc03c125fcbc5f4af5aae371eb37790b4b082d1f724acb1d209036ed65f57. Simulated Wait: 26.73 min
User-2 Swap executed: Output 100. New Pool: BCH=950, Tokens=1052
User-2 Merkle Root Updated: dc82e08db4b7f3f8915621ac690d8ee1a97a84ac97a43187fdb0d72ef6006e65. Simulated Wait: 10.58 min

> status
Pool: BCH=950, Tokens=1052, K=1000000
Merkle Root: dc82e08db4b7f3f8915621ac690d8ee1a97a84ac97a43187fdb0d72ef6006e65
Pending Commitments: 0

In this run, User-1 and User-2 race commits (simulated delays for network realism). The merkle root sequences them fairly—reveals process atomically on updated state, resolving contention without failures or long waits. A mismatched reveal (e.g., tampering) fails trustlessly: “Error: Invalid commit hash.”

Full Python script (CLI REPL with threading for races) and CashScript contract: [https://github.com/bastiancarmy/bitcoin-cash-trustless-defi-recursion]. Basics work today with 2018 OP_CAT, but 2026 upgrades scale it efficiently for real-world volume.

This could complement or serve as an alternative to the CHIP: The 2026 VM upgrades fix DeFi internals at the script level without the consensus risks of broader protocol changes—e.g., avoiding orphan spikes while preserving BCH’s foundational ‘soul’ and enabling ‘instant’ atomic batches for smoother UX.

3 Likes
#105

If two users calls commit() on the same UTXO at the same time both might be successful from their point of view, but only one will be mined.

2 Likes
#106

There seems to be a lot of arguments in favour of the proposal. Are they relevant, though?

Since then, technology has progressed immensely and a thriving industry of Bitcoin competitors (“altcoins”, near-universally preferring lower block times) has emerged demonstrating viability of shorter block times.

  • Yes, there is a technological progress. The progressing technology will require different, quantum-resistant cryptography soon. Quantum-resistant cryptography is not mature yet, but:

    • Quantum-resistant cryptography is already known to require a significant multiple of the data sufficient for the currently used cryptography.

    • Quantum-resistant cryptography will also require a significant multiple of the storage, network bandwidth and verification power.

  • The “altcoins”:

    • Did not demonstrate sufficient ability to handle the requirements of the quantum-resistant cryptography.

    • Economically, the “altcoins” demonstrated that a greater block frequency does not guarantee a market advantage:

      • Litecoin as an example demonstrates, that a 4x block frequency does not bring it an advantage over BCH sufficient to give Litecoin a higher market capitalization.

…services that don’t even recognize transfers as ongoing until the 1st confirmation arrives.

  • Services not recognizing transfers as ongoing until the 100th confirmation arrives are also possible. Does it matter, though?

Beyond actual waits, the blockchain’s pace feels slow because longer intervals dominate the timeline.

  • What does matter is only the actual wait, not the information how long a block confirmation interval appears to be to somebody not waiting for confirmation.

a 2014 American Express survey pegs 13 minutes as the maximum acceptable wait

  • Credit cards frequently have got a much greater settlement wait times than 13 seconds without their users requesting a shorter time.

  • See also the relation between the market capitalization of LTC and the market capitalization of BCH.

New users often onboard via established services, where confirmation delays can sour their first BCH experience. Reducing block times to 1 minute offers a practical workaround: it slashes 1-conf waits into the realm of user tolerance (e.g., 95% confirm under 3 minutes)

  • Not a serious argument. Who guarantees that the services would not require significantly greater numbers of confirmations after a block frequency change?

Compare this to Litecoin’s 2.5-minute blocks (where wait times will still exceed 3 minutes 30% of the time): BCH would leap ahead, offering a snappier experience than a key competitor.

  • Actually, the example of Litecoin demonstrates the opposite: As confirmed by comparing market capitalizations of BCH and LTC, there is no significant advantage of 2.5 minute block interval over 10 minute interval.

  • For the same reason why BTC does not compete with BCH in the media of exchange competition, LTC does not compete with BCH in the media of exchange competition in the long term.

core protocol changes don’t harm BCH’s image because they’re core changes, but because they’re poorly executed.

  • A frequent “BCH age argument” goes as follows: “BCH has got the same age as BTC, since it has got the same genesis block as BTC.”

  • Regardless of the above argument, the market treats BCH as younger than BTC as, e.g. the volatility lag of BCH compared to BTC demonstrates. What are the causes?

    • One of the causes is the fact, that the “Bitcoin Cash” name is more than 8 years younger than the “bitcoin” name. Note that this cause is not even technical. I can imagine that some might call it “cosmetic”, yet its influence on the market reception/perception/sentiment was radical.

    • The second cause is the fact, that Emergency Difficulty Adjustment (EDA) algorithm was not acceptable as a permanent solution and the Asert algorithm is much younger, possibly shortening the perceived “history length” of the coin even further.

    • I think that, at least according to its market effect, another cause of BCH’s lag is also the split in 2018 and perhaps also the split in 2020, although the splits weren’t really changing BCH.

  • Note that BCH is a coin. In numismatics, which is the original source of the coin’s value, history plays a significant role. The shorter the history is, the lower the value of the coin is and vice versa.

  • Therefore, we should not change several main characteristics of the coin like in this case (block frequency, block rewards, …), if we do not want to harm the market-established continuity of the coin’s history.

Summing up, I do not see serious reasons why to make these changes now. There are more important issues that have greater priorities.

2 Likes
#107

Welcome to BCH research! Glad to have you in the discussion.

Quantum related cryptography & faster blocks are orthogonal, unrelated issues. We can work on solutions & proposals for both at the same time (and are). Having quantum resistance solved does nothing to help the problems (transaction speed, confirmation reliability, user experience) that 1 minute blocks is trying to address, and vice versa. It’s not Quantum OR 1 minute blocks, it’s quantum AND 1 minute blocks.

Yes, if we can provide better technology, support, education or resources that convinces them to reduce their confirmation burden on BCH end users. Once again, it’s not OR, it’s AND. The choice isn’t between every service instantly moves to 0 conf, or every service demands 100 confs. We can move some of the services in the direction of less confirmations, which is a win on its own - although obviously it isn’t perfect.

This is not true. Endless user experience surveys show that the perceived speed is far more important than the real speed. Users get frustrated when something feels slow, regardless of whether it actually is slow. Something can feel fast and be slow, or feel fast and be fast, or feel slow and be fast. Ideally you want it to feel fast and be fast, but feel fast is often good enough on its own.

Yet again, this is just Nirvana fallacy. We shouldn’t set our standards at being equal to credit cards. We should get so much better than credit cards that people want to switch, which means being at least 10x better and ideally 10 000x better. Also, our competition is not only credit cards, but other cryptocurrencies (for instance ETH with a 12 second slot time, which they’re looking to reduce) and we need to get as competitive witht hem as possible too.

Nobody guarantees it. Nothing is perfect, and maybe (some) services will increase their confirmation burden. However, we can 1. communicate with existing major services to get a sense of their likely response ahead of time and 2. it defies basic logic that the vast majority of services would see a well tested upgrade and then go out of their way to avoid the benefit and even worse to actively reduce their own user experience and frustrate their customers. Of course someone MIGHT, but unicorns MIGHT pop out of the clouds from heaven tomorrow. Why would they do that? As some kind of weird contrarian “fuck you” to the BCH network for upgrading to help them out? Luckily, almost nobody is in that camp - actually they just want BCH to work & work better & they’ll be glad of the upgrade or at least happy to stick with their current security arrangement (increasing confs to match their existing time window).

Block reward is being adjusted & not (meaningfully) impacted. BCH is NOT the market leader, if we do not make changes & improvements we will lose by default. Ossification might be somewhat viable for BTC with its large network effect & liquidity - but for us it is death. We HAVE to offer a better solution, in as many aspects as we can, to win over network effect despite switching costs. 1 minute blocks is one way we can do that.

Yes, as mentioned above in multiple cases, you have a core misunderstanding that 1 minute blocks is mutually exclusive with other improvements - which it is not. The important thing is if 1 minute blocks makes sense in and of itself. If you think something else is a higher priority, definitely spend your time and energy working on that, but people working on 1 minute blocks have decided THAT is their highest priority and that work should not be wasted either.

2 Likes
#108

You opened by questioning relevance and then made an irrelevant first argument. We will have same TPS with any target block time because 3.2MB x 10 or 32MB x 1 is the same number of bytes. If signatures grow in size because of some PQC then we get less transactions per megabyte either way, and same TPS either way.

And Jason’s amazing work shows us that quantum-secure TX size can be kept under control by leveraging BCH smart contract and CashTokens capabilities, and if all '26 CHIPs get activated we can have quantum-secure wallets at no cost to TPS:

–

That’s a cherry picked data point, we only recently overtook LTC, and who knows - if we already had 1-min blocks maybe we’d have overtaken it sooner and now be even higher in mcap rankings.

LTC still has better on-chain stats, and is persistently ranking higher than BCH in BitPay stats.

Yes, because those that don’t even show pending transfer before 1-conf actually exist and affect at least some people’s BCH UX, while your hypothetical 100-conf service doesn’t.

Maybe I should word that argument better. I make a TX and merchant has me wait 1 confirmation. I have a habit of going to block explorer to monitor the status, so I open the explorer and see last block was 10 minutes ago, so “my” block must be coming soon, right? Nope, I end up waiting 10 more min., and my block shows as having taken 20 min. So the total time the block took amplifies my feeling of slowness. I myself waited 10 min, but the block took 20, and my impression of the chain will be affected. What % of the population is capable of reasoning about random process distribution and concluding that aKsHuAllY it is normal because random process and just accept to suck up the slowness.

1-conf services are 1-conf for BTC, BCH, LTC and DOGE, so clearly they just want the minimal PoW, and not more. BCH’s new minimal would take 1 min, so why would they go out of their way to require >1 just for BCH?

As for exchanges, even if they 10x the required number there would still be benefit in reduced variance of total wait time, and the progress bar effect.

More than just that: unbroken chain of blocks, unbroken emission schedule, and unbroken chain of custody. Every satoshi since genesis is accounted for in the audit trail which is our blockchain. Changing block time changes nothing here, the DAG of all transactions&headers will still correctly point to genesis. Block time is fundamentally nothing but a database config parameter to have some delay on database updates, it doesn’t affect database integrity.

Bad parallel. Numismatic coins are dead money, and not fungible. The numismatic coin itself typically has more value than the money it used to represent or the material it is made of. BCH aims to be live fungible money, rather than a dead collectible. Btw, are ordinals still a thing? That was an attempt to track numismatic value of coins, how did that go?

Block frequency is not a main characteristic and it is not breaking continuity and original block reward schedule will be preserved.

2 Likes
#109

That is just a funfair trick exactly like the “perceived wait time”. The reality is (3.2 MB x10 + 10 x block_header_size) versus (32 MB + 1 x block_header_size).

(When we ignore orphans, etc.)

#110

It is not a parallel at all. Every coin can (and does) become a subject of interest as a coin.

#111

I did present an obvious example that does not affect the database integrity either: the age of the coin’s name. However you want to ignore it, you cannot move the market sentiment.

#112

Yes, everyone seems to recognize BCH as being “born” in '17, and other forks and protocol changes didn’t “reset” that counter. So why should 1-min blocks reset the counter? They won’t. Btw both Monero and Zcash changed their block time, they still kept their age and identity.

1 Like
#113

This is called a “sperg dunk”, a factually true claim, but totally irrelevant. Each header is 80 bytes, the difference in size is less than 0.1%.

2 Likes
#114

That is an interesting, but false claim. I detect the coin’s age using some market characteristics and it is not true that the other changes did not influence the market’s perceived age of BCH.

#115

“detect”. You yourself attribute market moves to your arbitrary concept of age. Other market participants have their own reasons for wanting to buy or sell, and I doubt they consider your “age” at all.

1 Like
#116

Nonsense. I do not attribute market moves to “concept of age”. Other market participants have got their own reasons for wanting to buy or sell. Of course they do not consider “my concept of age”, they simply express their “sentiment” towards BCH in their buy/sell orders.

#117

What’s this supposed to mean then:

How would the market even perceive your “detected” age if nobody else uses this arbitrary method of detecting age?

I’ve had some arguments about 2009 vs 2017 as BCH’s birth year, but I haven’t seen anyone thinking that any later events reset people’s perception of age.

1 Like
#118

Nonsense.

  • Everybody perceives some BTC age. I just average the effects on the market based on the available data.
#119

Actually, BCH is (one of) the market leaders. E.g. BTC is not a competition, virtually everybody here knows why. USDT is not a competition any more than USD is. Etc…

#120

Literally all of BTC, USD & USDT are BCH’s competition. All crypto & fiat currencies (in fact, all objects literal and figurative in existence) are competing to be the most accepted currency.

So we need to be as good as we can in that category, because there’s so much competition.

#121

Funny. OK, a proof:

  • BTC has resigned on the media of exchange function. So, no, it is not a competition of BCH in the media of exchange competition.

  • USD is a competition, actually the strongest one.

  • USDT is not a competition, since by definition, it cannot survive USD’s defeat.