Although in my own personal opinion 1 minute blocks will help price, I think it is important that we refrain from any price arguments in regards to this CHIP.
Please keep it to technical arguments. No one actually knows or can know the effect on price.
Confirmation time is so important that ETH L2s are trying to find ways to innovate from a 2 second block time down to a 0.25 second block time!!
Weāve integrated Flashblocks, built by the team at Flashbots, reducing effective block times from 2 seconds to 250 milliseconds.
So I assume these āFlashBlocksā would be something like Infrastructure Blocks, but on ETH? Also with PoS instead of PoW?
Did I get it right?
PoW L1 will always be limited by practicalities like orphan rate and non-pruneable overheads.
Still, if we have a reliable L1 then us too can experiment with some PoS L2 (stake BCH to some L1 contract to become validator on L2) for high frequency trading or bespoke L2 for a retail payment solution.
L2s have their own risks and trade-offs, and our L1 needs to be good enough to keep enough volume on L1, because our security and future depends on L1 volume. Thatās why we still need 1-minute blocks even if we could get 0.25-second blocks on an L2.
This brings to mind the very insightful story of the technical guy that did marketing, he explained all that was awesome about his product and, as he is technical, noticed the problems in his explaining of how awesome the product is. He added that in the next release those issues will be fixed, however. It could be easy to overlook the fact that the product was indeed by far the best on the market.
The predictable result was that the people didnāt buy the product. Only very few got sold because the would-be customers ended up waiting for the next release. The end result is that the company went bankrupt.
The story illustrates that product quality and market share are not at all the same thing.
Being the best doesnāt lead you to be āmarket leaderā. And vice-versa.
This is all a long explanation of how Jeremy is utterly wrong about the above quoted conclusion. In a very dangerous and destructive way!
The way to get Bitcoin Cash marketshare to increase is based on first determining what your market is (how do you measure market share). Do you want to optimize for high price, or for lots of people using it as cash?
Most important step here is to realize that Bitcoin Cash is already actually technically superior over the vast majority of its competition. Which, as soon as you accept that, leads to the obvious question: but why are we not leading in those measurements we set ourselves as goal? In other words, why are we not market leaders?
This is when you really can get stuff moving, realizing that the product as is (the coin, the consensus rules, the community) is healthy and strong.
Then we can move to try to sell it to real people. Find out what needs work. Block waiting time is obviousy an annoyance, but not having repeat payments is a bigger one. Not having a 1000 different features that the banking system offers companies and users today are really quite a big more important to the sales-pitch than sometimes needing to wait.
Because at the end of the day, the competition is what people use already. Which is the banking system using fiat. Which is the products the banks and card companies ship. The apple pay / google pay / š pay. What do they have which the bitcoin cash experience lacks? Can that work be done in services and wallets? Or does it REALLY need to be the coin that is changing?
The focus on āchanging the coinā is misguided. The product is easily better than most (all) of the competition. If you donāt believe that, what on earth are you doing here?
If you DO believe that, go out and sell it. Go out and improve the wallets and the services to be able to do what people expect from a financial system.
Stop trying to push technical debt into the core of the coin because you think that helps you sell it easier. Thatās just lazy.
ps. as an aside, the term āmarket leaderā derives itās name from the leader being the first. Not the most successful. The market leader is very often the first to market and gains the most as a result. Dictating the market as a whole.
This also answers why market leaders are actually quite often NOT the technical best. Are often not the ones with the most features.
This further illustrating the point in bold at the top of my post.
Here is take in another context; first mover is extremely strong way to get a big market share. While often actually being the weakest technically.
This ties back to the bad take that in order for BCH to rise in price, it needs to technically be improved. This bad take is extremely damaging to our self-confidence, rating our technical-capabilities based on market value is not a good idea at all!
Lets make the rest of the world aware of what we already can do with the bitcoin cash chain. 
Why not do both?
When I came back into BCH the ABLA upgrade had just happened and I was super excited to see all the technical advancements that happened while I was not paying attention to BCH.
People will slowly trickle in, when they do show up it is a great strategy to have all the technicals in place so they can fully switch to BCH as it will be capable of everything, and doing it well.
Protocol upgrades are not paid by the people that decide they want to have them. They cost āusā all. They are a one time tax that companies have actuall stated are a reason for them to not support Bitcoin Cash.
The cost is mostly invisible to the many people discussing it on this forum, as they are not business owners, they are not node maintainers or infrastructure maintainers. The many people here discussing things like āfaster blocksā are essentially arguing for free cool stuff that āsomehowā happens with nothing more than them saying loudly that they want it.
But changes are not free to many others. Those maintainers, devops, designers, testers and many others need to put time and effort in it while getting mostly nothing in return.
And we are doing that, there are quite a lot of upgrades planned for 2026. Some more planned for after.
The cost/benefit of such changes is something that needs balance.
Heads up that Tom is desperately trolling for attention. Heās not going to make any logical arguments, he just wants someone to reply. Heāll say whatever he can to try and bait someone into asking him about it. He wants it so badly he was replying to his own posts to try snag someone & unfortunately you bit.
Just be aware of this pattern for future interactions.
At this time thereās no indications mods will put a stop to it, but it seems mostly everyone has learnt to avoid it regardless.
Wanted to share a blogpost @bitcoincashautist & @BitcoinCashPodcast brought up in Telegram that has been stuck in my mind. Jihan Wu supported shorter block times, and this old argument from the early days deserves more attention in this discussion.
Back in November 2017, he proposed it in the Chinese community and got immediate pushback from most people. But after a year, the majority flipped to support. A survey of the Chinese core communities found over 61% of supporters had originally been opposed before changing their minds. The BCH block size debate taught us that, sufficient discussion and patience tend to bring people around.
He basically had the whole CHIP written as a medium blog post back in 2019: https://medium.com/@ChangyongLiu/proposal-to-shorten-the-block-time-of-bch-1d7e8e897497
On 10 minutes vs 2 minutes doesnāt matter.
Why do we need shorter blocks when we have 0-conf
I love how cautiously rational the real Bitcoin community is. We will take Bitcoin back!
Iām opposed to this proposal for the following reasons:
In my view the risks outweigh the benefits.
Regarding the document itself, I commend the author on their herculean effort, however:
There remains much to explore in the non-consesus solution space. For example:
broadcast: false in WalletConnect and have the dApp broadcast the transaction. Since most dApps have one front-end, they can easily to made to bradcast via one node which will significantly reduce mempool divergence.Weird, I am not entirely sure I understand this argument.
The security, measured in 10 minutes in time, should remain pretty much constant.
Where does the 90% decrease of security come from?
Just to splatter my thoughts here from a twitter post the other day:
I am now mildly in favor of the proposal since I did find something useful out of it - I was previously purely on the side of (1, 2, 3) would just declare it outright not useful in practical applications. Iāve since found something I canāt just overlook - that it is useful to have locktimes on the order of minutes instead of hours. Even if security on those locktimes are weak!
With that said, what @rnbrady said in #4 here is significant, and Iām not gonna sugarcoat the complexity of a constant that is in every nook and cranny of the codebase. Unlike Litecoin weād also need to transition this. So I would leave it to more capable C++ hands to inform us how hard it is - is it '27 ready? better for '28? Or maybe if weāre gonna go for something that complex, maybe we should just go straight for Sunlight (more writeups and slides incoming)?
I donāt have good answers for these so Iām just gonna scurry back to my hole and work through it for now.
@ShadowOfHarbringer for applications currently hardcoded for one conf, the confirmation will come faster and with less variance, but carrying weaker security. So applications who do that would need to switch to 10conf to get the same weight.
Well, I just thought it should be obvious/natural that all the applications need to adjust accordingly if they require the same amount of PoW to confirm transfers.
1-conf applications rely on a single block, not on a 10 minute interval. A single block will arrive ~10x faster with ~1/10th the security.
I know.
Such applications (actually meaning: exchanges) will need to 10x the number of confirmations. This is what I am talking about.
Only if those 1-conf applications were particularly attached to the 1x10min worth of security. Letās examine few cases:
delay = delayCalc(outboundValue - (cloutScore - cloutUsed)) (source). Thereās a benefit here in that a $100 TX can require 1x1min conf and a $1000 TX can require 10x1min confs, where previously both cases would have to require 1x10min conf. Similarly to 1., if the value of our coinbase reward goes up - you can make higher value transactions at lower number of confirmation requirements.Another thing re. security. The 10-min target becomes more secure when itās made of 10 faster blocks rather than 1 slow block. A minority hash (<50%) can get lucky with a 1-conf reorg, but it canāt get lucky with a 10-conf reorg. Security against a minority attacker grows exponentially with number of confirmations, regardless of target block time! The calculation that demonstrates this is right there in the whitepaper (ā11. Calculationsā). Security against a majority attack grows linearly with chainwork (>50%), but with faster blocks it raises the hashpower threshold required to even try! It wonāt do to have 10% hash, he needs >50%. Where does he source it from? If we aim to become the dominant sha256d coin, we will reap max. benefits in that scenario. Imagine if BTC had 1-min blocks, you could do $200k TXs with 1-min 10-conf, maybe $100k with 5-conf, but 1-conf is still risky against minority hash so maybe still 3-conf for $10k.
Correct, the quote:
Reducing block times from 10 minutes to 1 minutes wouldnāt eliminate this problem, but it would shorten the average recovery wait to just few minutes, allowing users to retry faster.
Here I would like to add that it may reduce steady-state MEV by more than 10x. Canāt really make a strong claim, but itās just a matter of combinatorics. Do MEV opportunities grow linearly or super-linearly with set size? I suspect it is super-linear, because number of combinations of mempool TXs grows super-linearly. So the MEV/coinbase ratio is expected to reduce with faster blocks.
- Reducing block times from 10 minutes to 1 minute wouldnāt eliminate mempool contention (also a direct quote from the CHIP).
Correct, the quote:
Reducing block times from 10 minutes to 1 minute wouldnāt eliminate mempool contention, but it would cut the common recovery wait to under 3 minutes, enabling faster retries and improving user experience for all participants.
I donāt know if we can claim super-linear reduction of contention events per unit time, so for now I only claim faster recovery and less painful fallback to 1-conf.
Thankfully weāre not the first doing it. In 2019 Zcash changed theirs from 150s to 75s, and the Zcash PR is about 1k LOC (+813 -429). Now theyāre proposing to change it again from 75s to 25s, and are calling it a āsmall upgradeā:
This post proposes we lower the ZCash network block target spacing from 75s to 25s in a small upgrade this year.
If they had any problems with the first change in 2019 one would expect to see them discuss those issues now in 2026, but thereās nothing. Their main concern seems to be orphan rate. To me, this is very encouraging.
Re. AI: AI doesnāt introduce bugs, it discovers existing bugs. On the flip-side, canāt we use that same AI to help vet implementation? Re. low hash, I donāt follow what you mean.
Ticks can be thought of as cumulative target times, similar to how chainwork can be thought of as cumulative difficulty. Weāre just exposing it in APIs to potentially help at least someone become agnostic. But you donāt actually have to use it. Some downstream users are already agnostic. Consider Cashonize: does the wallet itself care about target block time? The user sees pending or confirmed all the same; the wallet displays the raw confirmation count. Does it really need to replace that with ticks? Not really. Zcash didnāt change their APIs, they still use height exclusively, and it looks like they didnāt feel the need to add this abstraction even when changing their block time for the 2nd time.
I think thereās no helping it, itās the result of people bringing up things and me then researching them and integrating into the CHIP 
Sorry, maybe I should tone it down a little. I was in āwe should stick to 10-min, thereās not much benefitā camp until I did the math re. variance and I really wanted to bring the point across, of just how unpredictable your wait time can be, and that those 30-min waits can happen too often. For what itās worth my other concern was re. locktimes & SPV but once I figured out the technicalities there I became confident we can have this change!
Disclosure: Iām a heavy AI user! I think in my first drafts not as much, but when LLMs got so good I started using them in many ways. I think I used some Grok initially, and months ago I switched to using Claude almost exclusively. Sometimes I just use it to proof-read and highlight stuff for me to fix, sometimes I discuss tech with him, show him code, etc. and then ask him to summarize or produce a paragraph that talks about it. Sometimes I just brainstorm, or use him for sanity checking. Sometimes I feed it discussions and ask to tell me what he sees there, and whether our CHIPās sections capture it well. I love Claude, heās been of great help, with the CHIP and more! E.g. he did most of the work in this other CHIP (āCHIP-2026-02: Simplified Header Verification for Bitcoin Cashā), there I was mostly just directing him, and we implemented the SHV CHIP, full set of libraries, and BCHN implementation, plus work on Electron Cash implementation (here, here, pending review). In fact, Claude actually prompted me to go research MMRs! I had this other CHIP (āCHIP-2025-03: Merkle Header Commitment for Enhanced SPV Scalabilityā) which I wanted to pick up again and try implement as proof-of-concept, and Claude recognized the pattern and told me it looks like an MMR.
I still use it like an ape, to me itās a magical chatbox at nano-gpt.com into which I c&p text and from which I manually c&p text. I do not have pipelines, automated workflows, agentic workflows. Iām just using it raw and chatboxed.
Ok, although I think Cauldron already has people independently interacting with the contracts and circumventing the front-end. John Galt anticipates our on-chain DeFi will result in fractured mempool state being the norm for DeFi steady-state. I can follow-up more on this later.
DSPs and ZCEs donāt work if the TX is spending non-P2PKH inputs. When people extend their 0-conf DeFi chain to pay at merchant then merchant should require 1-conf because DSP score is 0. The DeFi chain may get mined or it may get nuked, but with 1-min blocks chances are that by the time you get to merchantās checkout: your payment to merchant will be spending confirmed UTXOs. With 10-minutes, your DeFi chain may still linger, merchant would ask 1-conf, your DeFi chain could get nuked, only for you to find out your payment to merchant got cancelled. But at least after that you can pay with 0-conf from your walletās pre-DeFi state.
Yes they do, and I guess it could be made user-choice, but I didnāt really study this much to be able to say more.
and MTP will lag by real clock not by 1 hour but by 6 minutes!
Iāll just copy the same reply I gave to Richard:
Donāt faster blocks help set the stage? Suppose you want to publish these partial PoWs every 12s. How many sets can possibly accumulate before a block is mined and resets the game? With 1-min blocks maybe the worst case is 6min so you accumulate 30 sets, sounds manageable. With 10-min blocks, a 1h outlier could result in nodes having to analyze 300 sets. How much memory is needed and how does the ābig Oā scale here? We had some chat about it the other day, posting here so itās not forgotten: Telegram: View @bitcoincashnode
By the way, some questions about Sunlight. Does it even help with stuff like MEV? If miners A and B are each funneling some MEV to themselves, the mempool will still be partitioned, but it will be public knowledge how much hash% is mining one version and how much hash% is mining the other. It helps merchants more than DeFi, even if miners A and B are fighting over some MEV; because it will be public knowledge that those 2 sets intersect in some TXs, and those TXs will have a high chance of being confirmed in the next block so can accept 0-conf, even if some other TXs will be in conflict. For those in conflict, people will have to await 1-conf still, right?
Their implementation is 1k Lines of Code, yes.
However, did they also implement ticks? That is unclear.
I seriously doubt you can make 1 min + ticks with just 1 thousand LOC, but I could be wrong - I am not an active BCHN dev.
I would imagine itās 300% higher number of Lines at least. It could be that every fundamental line of code controlling mining, relaying and whatnot could be touched.
Please tell me I am wrong.