Welcome aboard. Glad to have you in support!
2 Likes
Yes, I saw his posts and the conditions but I have also sensed some hesitation from his side. But if Calin changes his statement and indicates he is happy with the implementation, the testing, and the parameter choice I will change my statement too. As long as the implementation quality is there, I agree with you on moving on this while everyone is engaged and not drag it out unnecessarily.
I was mainly thinking BCH relative other chains with the same architecture and failure mode (a blockDAG is different (Kaspa), and a chain with self adjusting block time does not need the same margin up front (Nervos)). So once the Zcash update goes live, the block time range is 25s to 10 min (for similar top chains), positioning 1-min blocks towards the lower end.
The CHIP model for block propagation time and orphan rate is great within its realm but I don’t think it covers for scenarios that degrade the underlying network severely. True, the model does take the amount of missing transactions is a model input (expressed as a percentage of a block) and it can be dialed up to 100%. But assuming an increase in missing transactions is caused by network degradation, the CHIP equations don’t take into account other factors that would accompany network degradation. For example, packet loss can lead to significant reduction in throughput but the CHIP equations assume constant throughput (peer_bandwidth). Packet loss also introduces TCP related delays (fixed timeouts or extra roundtrips) not accounted for in the equations. Some of these hit as latency for block propagation so they affect lower block times more. I don’t think we can use the CHIP model as an upper bound on block propagation time and orphan rates under severe network degradation scenarios. Under such scenarios the block propagation time could start to approach the block time. An example scenario is if the cross-regional links connecting the two main mining regions are severely degraded due to cable cuts and resulting overload. Then transactions may still flow across this link but cross-region block propagation time as a share of block time could rise high and this state could be sustained for months (everything else equal).
It wasn’t that clear from my post but I am ok with lowering the block time as long as the BCHN implementation is solid. Personally I might have been slightly more conservative in the parameter choice. But it is not a huge difference and at this point I’m mainly interested in making sure the trade-off is understood.
Re. Jason: I’m aware of Jason’s view on 1-min blocks. I linked his tweet because it touches on the topic of “storms” and the trade-off.
2 Likes
We’re on the same page then, and I appreciate your feedback! It made me re-think something.
Kaspa doesn’t belong there, but Nervos does. It’s still a chain, and the algo works by miners committing observed orphans somewhere, so algo can read it and respond. There’s no reward for this and no penalty for omission, it’s purely voluntary. This creates incentive for bigger pools to under-report, and AFAIK their 10s is actually pretty close to the algo floor (8s). I pointed this out to them: Telegram: View @utxoalliance and mentioned it in my Evaluation of Alternatives: Algorithmic Target Time.
But maybe I’ve been looking at it wrong. What if it’s supposed to be at the floor, but ability for miners to feed in orphaned headers is just a contingency plan: exactly to be used in scenario you’re concerned about. One more tool in the toolbox, before having to make an emergency/contingency hard fork. Similar to how with ABLA they can just limit their own block sizes to stop the algo from moving the limit up, or force it to reduce. This could be worth some research and maybe a future CHIP.
It doesn’t have to be read as constant - it can be the average, then orphan rate averages, too. With transient issues, you’d hit maybe 3%, then 1%, and still average at 2%. Same for latency, think of latency as the average. Mining is a game of averages. If you can maintain the averages, you profit. If you can’t, you don’t.
Also, taking SN’s 10% consideration, suppose a bottleneck between regions happens and when announcing block to each other they have 10% (~6s prop time!), but when announcing to local miners they have 1%, it again averages out to 5.5% – if clusters have 50:50 hash distribution (e.g. America / Asia split). Note the model over-estimates the average orphan rate because orphan probability is concave in propagation time, so by Jensen the time-averaged orphan rate is at most the orphan rate computed at the mean propagation time.
Of course, a sustained regime shift would move the average too far, and in that case miners can only reduce block sizes and try to patch up the network ASAP to restore propagation to something tolerable. Which makes me think something like that algo from Nervos could be a valuable addition.
3 Likes
Keep in mind it’s not really toward the lower end once you look at the distribution:
It’s not a smooth distribution from 25 seconds to 600. Actually 600 is by far the outlier. And it’s only occupied by BCH (which is looking to change it based on the data) & BTC (which was set in 2009 & is effectively ossified & will never change it again no matter how overwhelming the evidence for it).
This is for all Top 100 coins, but it makes the point generally.
And here is the data filtered to only top 20, and only native coins with their own network.
Which looks like this:
So even an argument that we should “shoot for the middle of the range” or “be conservative” (which I don’t think is a particularly great way to approach the problem, but I understand the instinct) means BCH at 1 minute is actually STILL conservative. By that logic, we should actually be going FASTER than 1 minute.
Even if we be EVEN MORE selective with the coins (throwing out fairly relevant comparisons like Cardano) and cut down to just this list of old-school PoW style:
- Zcash: 25s (adjusted from 75s)
- Dogecoin: 60s
- Monero: 120s
- Litecoin: 150s
- Bitcoin and Bitcoin Cash: 600s
60s does not look aggressive at all, it really looks very moderate. Again, BTC is barely event relevant to the discussion because its choice is more of a historical accident than a research-informed decision.
5 Likes
As BCH becomes more popular people will use it in all types of situations, many of which will require a conf or two. If they get hit with a huge delay it will be an instant turn-off. This needs to be addressed ASAP.
5 Likes
That’s true when you look at it as a vote of confidence in a given block time. My perspective was also: as we dial up the storm, which blockchains will still be operating properly/sustainably assuming the storm is drawn out.
2 Likes
If the storm is drawn out, which blockchains come out the better has far less to do with their block time or any other technical merit, than with their community’s ability to socially re-coordinate under the particular conditions of the storm.
Ie the BCH community with the CHIP process and with a general high concentration of good actors would theoretically outperform Litecoin, but underperform ZEC if their centralised dev team was fine (everyone would just reorg under the main Foundation team) and massively overperform it if the ZEC main guys were inaccessible due to the storm (it would be complete chaos).
So block time isn’t really the deciding factor there. The better thing is to make the social layer as decentralised and well-practiced at coordinating as possible, and likewise distribute the technical infrastructure (in terms of experienced devs, mining hardware, nodes, major infrastructure providers like wallet teams) as dispersed as possible too.
5 Likes
Yes, if relevant people are available we can coordinate a raise of the block time in such a storm. I agree, a decentralized BCH community used to delivering changes helps resiliency, and with ticks it is a less risky change. For somewhat smaller storms (say 15s block propagation) then some miners will lose business, but other businesses like payment processors may be against a raise of the block time. If the change is contentious that may favor a drawn out status quo.
2 Likes
It’s also worth remembering, that in a persistent storm, a chain split isn’t actually that big of an issue. Blockchains are default resilient to that in large measure.
If 85% of people are on Chain A and 15% of people who are in their own little echo chamber fork off to Chain B, they can continue transacting and you just have two chains running. For all transactions that aren’t double spends and are just occurring among the 15% - those transactions can be replayed (and nobody is harmed, even for children of children of children transactions afaik) onto the 85% main chain once connection is reestablished.
If the two groups are silo’d, then there isn’t a lot of double spends or overlap that will create problems, and reconciliation will be fairly easy once you re-establish connection. The exact block the transaction is included in will change obviously, but the transactions themselves don’t - since they flow from the same previously unspent UTXOs or the related isolated children.
If the two groups have intermittent connection, then you do have more chance of overlapping problems but also you get more frequent chances to reconcile everyone up to the same state.
So either way the blockchain is fairly resilient to it, and usually able to reconcile nicely for good actors even with significant disruption.
4 Likes
Faster blocks and covenant-settled applications: evidence from DeFi, ZK, and privacy
I work on CashNotes (formerly BCH Cloak), a private note transfer protocol for Bitcoin Cash. Comparing its settlement model with Zcash highlighted where block time matters for covenant applications.
This is not an argument about payment UX generally. It is specifically about applications whose state transitions depend on confirmed covenant spends.
1. Covenant spends don’t get the usual zero-conf protections
BCH payments can often be accepted quickly because nodes relay double-spend proofs when conflicting spends appear. Bitgree, for example, waits four seconds for a proof before accepting.
But DSProof only covers transactions whose inputs are P2PKH with SIGHASH_ALL. The proposed ZCE has the same P2PKH-only constraint.
Covenant spends therefore sit outside that protection: AMM swaps, contracts that verify proofs, private note transfers, and other contract state transitions. For those cases, the DSProof specification’s guidance is to “wait for confirmation”.
The issue compounds when applications chain transactions, where each stage spends the output of the previous stage. If an earlier transaction is replaced, later stages disappear with it.
| Block interval | 1 confirmation: typical | 1 in 20 waits longer than | 3 chained confirmations: typical | 1 in 20 waits longer than |
|---|---|---|---|---|
| BCH today, 10 min | 6.9 min | 30 min | 27 min | 63 min |
| BCH at 1 min | 42 s | 3.0 min | 2.7 min | 6.3 min |
| Zcash today, 75 s | 52 s | 3.7 min | one transaction | one transaction |
| Zcash NU7, 25 s | 17 s | 75 s | one transaction | one transaction |
For covenant applications, the practical rule is roughly:
settlement latency ≈ number of sequential confirmed stages × block interval
There is an important distinction between confirmation count and accumulated work. The CHIP’s security analysis specifies one tenth the chainwork per block while preserving approximately the same chainwork accumulation per unit time. Ten one-minute blocks therefore accumulate approximately the work of one current ten-minute block.
That means one-minute blocks provide earlier, smaller increments of confirmation rather than making ten minutes of accumulated proof of work arrive sooner.
Effect of 1-minute blocks: strongly helpful when an application benefits from earlier confirmations; neutral where it requires the same accumulated chainwork as today.
2. Zero-knowledge applications
ZK applications can require multiple covenant transactions because verification and subsequent state transitions must fit BCH transaction and unlocking script limits.
There are two ways to reduce that latency:
- reduce the number of required transactions;
- reduce the time between confirmations.
New opcodes could eventually reduce transaction count, but CHIP-2025-05 covers secp256k1 arithmetic and leaves pairing and STARK verification to separate proposals.
Until then, block interval directly limits sequential covenant state transitions. A state machine that requires each parent to confirm can advance about six times per hour at ten-minute blocks versus about sixty times per hour at one-minute blocks.
The main concern is orphan rate. The CHIP estimates 0.41–1.94% at one-minute blocks.
Zcash offers a useful comparison. Zakura reported roughly 30% orphan rates during testing with 25-second blocks because proofs were being verified twice. After reusing mempool verification results, the rate fell to about 3.6% (Zakura 1.2.0).
BCH Node already caches script validation results from mempool admission and reuses cached results during block validation.
The remaining case I would like to see tested is blocks containing expensive transactions that verify proofs and that nodes have not already validated through their mempools. The CHIP considers this attack surface and argues that BCH’s VM limits and signature check limits bound worst case validation cost. It also scales maximum block size from 32 MB to 3.2 MB along with the shorter interval.
Those are useful analytical arguments, but Chipnet could provide empirical evidence that validation and propagation behave as expected when blocks contain significant amounts of proof verification.
Effect of 1-minute blocks: helpful for ZK applications because they reduce sequential settlement latency. Whether transactions requiring expensive proof verification impose a meaningful validation penalty at the shorter interval is a specific question that can be tested.
3. Proving time
Faster blocks do not make zero-knowledge proofs faster. They only reduce the confirmation delay after proving.
Zcash wallet developers report shielded proving times of roughly 142–550 ms on phones.
That distinction matters:
- if proving completes well within a minute, block time dominates user visible settlement latency;
- if proving or batching takes several minutes, reducing block time has less impact.
For a BCH application that proves quickly, a typical one confirmation wait falls from about 6.9 minutes to 42 seconds.
Effect of 1-minute blocks: helpful when proving is already fast; increasingly neutral as proving or batching becomes the dominant source of latency.
4. Competitive position versus Zcash
Zcash currently uses 75-second blocks, giving a typical one block wait of about 52 seconds.
NU7 moves to 25-second blocks and has been live on public testnet since 5 October 2026, with mainnet targeted for 5 November.
Its proposed Project Tachyon would allow block producers to aggregate shielded transactions without user coordination.
CashNotes uses a related model without a consensus change: users prove locally, then permissionless aggregators batch proofs and settle them through covenants. The difference is where aggregation occurs:
- Zcash aggregation can settle within block production;
- BCH aggregation may require multiple sequential covenant transactions.
For a three-stage BCH settlement:
- 10-minute blocks: ~27 minutes typical;
- 1-minute blocks: ~2.7 minutes typical.
That does not match a one block Zcash settlement, but it moves BCH from an order of magnitude disadvantage toward a difference of minutes.
Effect of 1-minute blocks: clearly helpful competitively. They do not erase Zcash’s latency advantage, especially at 25-second blocks, but they substantially narrow it for covenant privacy and proof applications.
Conclusion
For conventional BCH payments, faster blocks are less important because zero confirmation mechanisms already provide useful payment UX.
For covenant applications, the situation is different. DSProof and proposed ZCE protections do not cover covenant spends, and many applications require sequential confirmed state transitions. In those systems, block interval becomes application latency.
Moving from ten-minute to one-minute blocks would:
- reduce a typical confirmation from about 6.9 minutes to 42 seconds;
- reduce three sequential confirmations from about 27 minutes to 2.7 minutes;
- increase confirmation dependent state update capacity from roughly 6 to 60 updates per hour;
- substantially narrow BCH’s latency disadvantage for covenant privacy, DeFi, and ZK applications.
The security tradeoff is narrower than simply saying that faster blocks provide less security. The CHIP preserves approximately the same chainwork accumulation per unit time while dividing it into ten smaller increments: one tenth the chainwork per block and one tenth the maximum block size.
Its security analysis argues that most relevant properties scale with those changes. It also identifies effects that do not scale perfectly, particularly fixed network latency and the resulting propagation races.
That is the part I would like to see examined adversarially and tested on Chipnet. The question is not whether ten one-minute blocks contain roughly the same accumulated work as one ten-minute block; they do. The question is whether dividing block production into smaller, more frequent increments introduces practically significant behavior that the current analysis or assumptions do not capture.
Position: neutral, but strongly interested in being convinced
My incentives as an application developer point strongly toward one-minute blocks.
My goal with CashNotes is to make private payments and applications using cryptographic proofs on BCH competitive with what can be built on any chain. From that perspective, reducing settlement that depends on confirmations from tens of minutes to minutes or seconds would be a significant improvement.
What keeps me neutral today is narrower: I want stronger evidence that the change in block cadence and chainwork per block does not introduce a meaningful security disadvantage that outweighs those benefits.
The CHIP provides a substantial analytical case that security per unit time is preserved and it bounds several specific attack vectors. I would like to see that analysis subjected to adversarial review and, where possible, empirical testing, particularly around propagation, orphan behavior, and blocks containing transactions that require expensive proof verification.
If that evidence supports the CHIP’s security analysis, my position would move from neutral to strongly in favor. The application benefits are already clear to me; the remaining question is whether the security assumptions continue to hold under adversarial conditions and workloads involving substantial proof verification.
Sources are linked inline. The waiting times are closed form calculations from exponential and Erlang distributions, and I’m happy to share the script.
Disclosure: I drafted this with AI assistance, then reviewed, edited, and verified the arguments and figures against the sources linked above.
3 Likes
Side note, there’s an important distinction between minority and majority (or supermajority) attacker, see here for some follow-up discussion: CHIP-2025-03 Faster Blocks for Bitcoin Cash - #210 by bitcoincashautist
Above, @joemar_taganna independently replicated many of the CHIP’s claims, which actually made him flip to support: CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent) - #70 by joemar_taganna
Today, @bitjson independently discovered an error in my specification, and posted about it literally ~50 minutes after I had pushed the fixing commit. I didn’t know he had found it, nor that he was about to post about it. That actually gives me confidence:
- Other people are watching / reviewing, and they would actually catch something I may have missed.
- The only issue found so far is one I had already closed, and it was a two-line fix.
And I caught it because producing reference implementation and test vectors is part of the CHIP process, as is people reviewing it, and it all worked as it should.
He’s also preparing to support us by launching a “tempnet” as soon as code-build is ready, so we will have opportunity to do some testing even before forking chipnet.
On the chainwork distinction — you’ve stated it exactly as the CHIP does, and there’s a section that works through the consequence: Confirmation Count vs Tick Thresholds. The short version is that height-mode locktime and sequence are normalized to 600-tick units, so a contract asking for “+1” gets ten 1-minute blocks rather than one 10-minute block — the same wall-clock delay with more underlying confirmations, hence more statistical finality against a minority attacker, not less.
For the accumulated-work case specifically, parking and finalization are tick-scaled, so their wall-clock thresholds don’t move: parking lock-in stays at 2,400 ticks (~40 min) and finalization at ~120 min. An application that needs that depth waits the same either way; one that only needs a few confirmations gets the 10× improvement.
On expensive proof verification: the analytical answer is that both the per-block limits and the block size scale 10× with the interval, so worst-case validation time as a fraction of the interval is invariant; the only non-scaling term is fixed network latency, which is already the dominant term in the orphan model. So there’s a predicted answer, not just an open question — the orphan rate should land in the modeled 0.4–1.9% band at 60 s. Chipnet (and @bitjson’s tempnet) will produce the measurement.
On the Zcash orphan data — that’s a stronger corroboration than it may look. 3.6% at 25 s with cached verification implies an effective propagation time of ~0.92 s, which sits inside the CHIP’s modeled band (0.25–1.18 s) and better than the CHIP’s pessimistic 1.94% case, which assumes zero mempool overlap. Zcash’s 30% → 3.6% before/after caching is the CHIP’s “100% missing” vs “synced” distinction measured on a live chain. I also hopped on their forum, shared some notes, and predicted they could get 4.26% network orphan rate with their 25 s blocks: Zcash Block Time Reduction Appears Safe for NU7 w/ Zebra Only Devnet - #4 by bitcoincashautist - Zebra - Zcash Community Forum — that prediction implies ~1.09 s propagation, within ~8% of the CHIP’s own pessimistic 1.18 s assumption, derived independently for a different chain.
3 Likes
Hi,
This is my first post, I don’t know how to reply properly.
I support faster blocks, I have been struggling a lot with 1h30’ waitings for gettin 1 single conf,… it its frustrating.
I know there is a lot of fear with this one but I trust the devs and OGs that also supported this inititative.
We need it. Newcomers who come from blockchains that gets 1 conf with 1-3 secs can’t come to bch make a cross chain swap and wait 2 hours, that’s lame, that’s horrible, feels like a scam. It causes real pain. This issue must be addressed. “hey, but 0-conf blablabla” yeah, nothing works with 0-conf and 0-conf can still be a thing, we are not eliminating that, thank you for your useless opinion.
Even bch defi needs 1 conf to solve some conflicts. Cauldron uses 1 conf to solve when 2 swaps happen at the same time. ParyonUSD uses 12 conf to blabla… people who think that can ignore conf time make me think that they are not actively using bch… well I am, and I can’t stand 1h’30m waits for 1 conf. let’s go with it. I SUPPORT faster blocks.
6 Likes
Welcome to BCH research! You can highlight a section of text and then click “quote” to quote it when writing your responses. It’s not the most intuitive system.
“thank you for your useless opinion”. 
Not the most diplomatic way of saying it, but you’re absolutely right, all this “what about 0 conf” is a completely pointless red herring since nothing is changing with 0 conf for anyone who is satisfied with 0-conf in any and all circumstances.
3 Likes
Yup, Faster blocks are much overdue. I honestly think we would have significantly higher adoption by now if we put in faster blocks a few years ago. It could have gone in along side the ABLA upgrade back in 2023 or even before.
5 Likes
Historical nit: ABLA went live in 2024, not 2023.
But yeah you can see how much work is going in to convince everyone of this idea even today. No way we would have been able to get everybody to agree to it at the same time as CashTokens or ABLA (which themselves were big and impactful changes which took a ton of work), especially when the community back then was far more traumatised and fragile having just had 3x chainsplits and CoinFlex meltdown in recent memory.
So 1 minute blocks is coming at just the right time. But if we have to delay a whole extra year that is going to be a real loss of momentum.
4 Likes