Hi everyone. This is my first post here, so please forgive me if I misunderstand some technical detail or repeat something that has already been addressed. I’ve been reading the proposal and the discussion, and I wanted to share some concerns and hopefully understand the case for the change better.
First, I want to say that I do see substantial benefits in moving to faster blocks.
Reducing the gap between instant 0-conf payments and transactions or services that require confirmation seems genuinely valuable. More predictable confirmation times, better UX for exchanges and wallets, faster recovery from situations where 0-conf cannot be used, improvements for some DeFi and cross-chain use cases, lower short-term mining variance, and potentially better behavior during large hashrate changes all seem like meaningful advantages.
So my concern is not that 1-minute blocks provide too little benefit to be worth discussing. I can see why this proposal is attractive.
What makes me uncomfortable is the amount of systemic change required to obtain those benefits, and especially the transition from a network and ecosystem that has been built around a roughly 10-minute block target for many years to one operating at 1 minute.
One concern is network convergence and propagation.
A newly mined block takes some non-zero amount of time to propagate, be validated, and become the chain tip that miners across the network are building on. I understand that blocks would become proportionally smaller, that modern block propagation is much better than it used to be, and that the proposal explicitly analyzes the expected increase in stale/orphan rates.
Still, bandwidth improvements do not eliminate network latency. Reducing the target interval by an order of magnitude necessarily makes fixed propagation delays a larger fraction of the interval between blocks.
I understand the argument that the resulting stale rates are expected to remain within tolerable limits. My hesitation is whether demonstrating that a loss of some propagation margin is tolerable is necessarily the same as demonstrating that consuming that margin is desirable.
Having better propagation technology can be used either to safely support shorter intervals or to leave the network with greater robustness under imperfect conditions. I am unsure where the best balance lies, particularly if BCH eventually operates under much heavier usage, less favorable network conditions, imperfect mempool synchronization, or temporary connectivity problems.
Related to this, I am also interested in the decentralization effects.
My understanding is that higher stale rates can create some advantage for miners with better connectivity and propagation infrastructure, because those miners may lose proportionally less work in competing-block situations. Even if this effect is small, a persistent advantage of that kind could create some centralizing pressure.
On the other hand, I also understand that finding blocks more frequently reduces short-term mining variance, which may benefit smaller miners and pools.
Because those effects point in opposite directions, I don’t think it would be accurate to simply say that shorter blocks centralize or decentralize mining. What I would like to understand is how confident we can be about the net effect in the real BCH network, and how much of that confidence comes from empirical evidence rather than models.
But my biggest concern may actually be the transition itself.
Bitcoin Cash is not only the consensus implementation. There is a large surrounding ecosystem of wallets, exchanges, explorers, indexers, SPV clients, mining software, payment processors, APIs, libraries, scripts, contracts, private integrations and services developed over many years.
Some of these systems may contain explicit or implicit assumptions about block frequency.
The obvious examples are applications that reason in terms of confirmation counts or use block height as an approximation for elapsed time. After the change, one confirmation would arrive much sooner and would represent roughly one tenth of the expected accumulated proof of work that one confirmation represents today. Applications that actually depend on the current security meaning of “1 confirmation” would need to adjust.
Well-maintained exchanges, wallets and infrastructure providers can be informed and updated. What worries me more is the long tail: old software, abandoned libraries, closed-source services, private scripts and integrations that nobody involved in BCH development necessarily knows about.
And I think the more dangerous failure mode is not necessarily software breaking completely.
A program that crashes after the upgrade is visible and can be fixed. A program that continues running while its assumptions about confirmations, block height, elapsed time or security have silently changed may be much harder to notice.
That is why I wonder whether the migration risk deserves as much attention as the steady-state behavior of the new network.
How can we know when the ecosystem is sufficiently prepared?
Would it make sense to have an extensive test period under realistic conditions, a formal compatibility/readiness process, documentation specifically aimed at third-party developers, an inventory of common assumptions that need to be audited, and outreach to major infrastructure providers well before activation?
I would also be interested in whether there is any practical way to identify less obvious dependencies on the current block interval before activation rather than discovering them afterward.
More generally, my inclination with consensus changes is to be conservative, but I don’t mean that the status quo should be preserved simply because it is the status quo. Ten minutes is not a sacred number, and if technology has advanced enough to safely obtain meaningful benefits from a different interval, I think that deserves serious consideration.
My concern is that changing an established consensus parameter by 10x has a very large blast radius. Some risks can be modeled reasonably well inside the protocol, while interactions with an open ecosystem of third-party software seem much harder to bound.
So at this point I am not convinced that 1-minute blocks are a bad idea. In fact, I think the benefits described by the proposal could be significant.
I am mostly trying to understand how confident we can be that:
- the reduced propagation margin remains sufficiently robust under adverse and future conditions;
- the net effect on mining incentives does not create meaningful centralizing pressure;
- third-party software does not silently inherit incorrect assumptions after the change; and
- the transition itself can be made conservative enough that we do not discover important dependencies only after activation.
For people who have worked on this proposal much more deeply than I have: what gives you the most confidence specifically about the transition risk? And what safeguards or readiness criteria would you consider sufficient before making a change of this magnitude?
I’m asking sincerely. I see real value in the proposed benefits, but I would like to better understand how we can obtain them without taking unnecessary systemic risk.
