What changes and what doesn’t
The reward and per-block limits are divided by ten, so issuance and hourly capacity stay the same. So that rules that count blocks today keep working, the CHIP adds ticks, a unit of idealized time.
| Today: 10 min | CHIP: 1 min | |
|---|---|---|
| Blocks per day | 144 | 1,440 |
| Issuance and hourly capacity | same | same |
| Work behind one confirmation | 1 | ≈ 1/10 |
| First confirmation: wait over 14 min | 24.7% | < 0.1% |
| Mean wait to match today’s 15 confirmations | 150 min | 150 min |
| Header chain growth | 4.2 MB/yr | 42 MB/yr |
| Estimated orphan blocks per day | — | 6 to 28 |
The CHIP’s technical quality is high. The question is whether it should be activated, and whether it’s the right way to solve what it says it solves.
What the CHIP is after
Responding to the objection that its list of benefits kept changing, the author said that the CHIP’s goal is to deliver faster blocks, and that each kind of user would experience them differently. These are the arguments in favor, in their best version:
- Faster first confirmation
- For cross-chain swaps, payment gateways, and multi-currency wallets that don’t accept 0-conf. 95% would arrive in under three minutes.
- More predictable multiple confirmations
- For high-value operations, the wait would have much less dispersion.
- Faster recovery in DeFi
- When two users collide on the same UTXO, retrying would take one to three minutes instead of ten to thirty.
- A “sliding scale”
- Finer choice between speed and security: “$100 of security in 1-min, and $1000 of security in 10-minutes.”
- Secondary benefits
- Finer locktime granularity, more frequent payouts for small pools, and a difficulty adjustment that reacts sooner.
- The cost of doing nothing
- New users compare BCH to faster chains, and every year more software assumes ten minutes as fixed.
The question isn’t whether these benefits exist, but whether they justify what they cost, and whether this is the right way to get them.
The problem is real, but the change doesn’t eliminate it
In the three cases used to justify the CHIP, the problem still exists after the change.
2.1One confirmation: a real improvement
Block intervals follow an exponential distribution: the average wait is ten minutes, but the spread is as large as the average. According to the CHIP itself, one in four transactions waits more than 14 minutes, and one in seven more than 20.
With one-minute blocks, the first confirmation arrives much sooner. That benefit is real, and it should be acknowledged.
Exchanges: predictability, not speed
Kraken currently requires 15 BCH confirmations. With one-minute blocks, comparable security would take about 150. The average wait would be the same: about 150 minutes.
What changes is the dispersion: with six ten-minute confirmations, the probability of waiting more than 90 minutes is 11.6%; with sixty one-minute confirmations, 0.03%.
2.2DeFi: the collision still happens
When two users act on the same UTXO, nodes see different versions of the mempool and one transaction fails. With one-minute blocks the error lasts less, but it keeps appearing. As rnbrady put it: “We should solve the problem completely.”
The fix belongs in the layer where the problem arises: ordering requests in the application and flagging collisions with DSProofs.
2.3A permanent solution to a temporary problem
Many of the cases the CHIP cites depend on centralized third parties: exchanges, gateways, and multi-currency wallets that require confirmations. BCH’s recent upgrades, such as CashTokens and native introspection, aim precisely to depend on them less. Permanently changing a protocol constant to better accommodate the actors the network is trying to become independent of is contradictory.
The costs
They are concrete, and nobody has measured them yet.
3.1SPV clients: the central cost
The cost falls hardest on precisely the wallets that depend least on third parties.
| Wallet type | Example | How it works | Impact |
|---|---|---|---|
| True SPV | Flowee Pay | Downloads every header and requests filtered blocks; verifies each payment without relying on a server. | High |
| Electrum protocol | Electron Cash | Downloads headers from a checkpoint. | Medium |
| Server-backed mobile | Many | Queries Fulcrum servers; the cost moves to the server, and dependence on it grows. | Indirect |
| Dimension | 10 min | 1 min |
|---|---|---|
| Header storage | 4.2 MB/yr | 42 MB/yr |
| Syncing one month | 4,300 | 43,000 |
| NFC payment with a week of headers | 80 KB / 1.5 s | 800 KB / 15 s |
3.2Less work per block, little orphan margin
A one-minute confirmation is backed by about a tenth of the work. To Calin Culianu, lead developer of BCHN, it “feels fundamentally wrong” to divide a chain with a tiny fraction of total hash this way.
The higher the orphan rate, the bigger the advantage of large pools. The CHIP’s worst modeled case sits six hundredths of a point below the threshold it calls tolerable. The real rate will only be known with the network running.
3.3Permanent complexity
Ticks solve contract compatibility, but add an abstraction that stays forever: block heights, ticks, confirmations in blocks, and confirmations in ticks. What Culianu likes least is the redefinition of nLockTime, which makes those fields very hard to reason about.
“It’s like a NUKE went off in the codebase. Everything got touched.”
Calin Culianu, BCHN, October 2026
3.4Unquantified activation costs
The CHIP describes the costs for nodes, mining, exchanges, wallets, explorers, indexers, and DeFi as “real but bounded,” without numbers. Teams being aware of the proposal is not the same as having estimated what it costs them to adapt. The main risk, which the CHIP itself acknowledges, is software that credits deposits by number of confirmations and ends up requiring, without knowing it, a tenth of the work.
3.5Improving one experience by worsening another
For many people, “confirmed” means “final.” When a block is orphaned, an honest payment isn’t lost: it gets into the next block. But a merchant waiting for one confirmation sees it change status. And reversing a one-confirmation payment becomes about ten times cheaper for an attacker, and nobody tells the merchant.
- t = 0Confirmed1 confirmation
- +1 minUnconfirmedThe block was orphaned
- +2 minConfirmedIncluded in the next block
Principles
- 20178 MB blocks, new difficulty adjustment10 min
- 201832 MB blocks10 min
- 2019Schnorr signatures10 min
- 2020ASERT, third difficulty algorithm10 min
- 2022Native introspection10 min
- 2023CashTokens10 min
- 2024ABLA, adaptive block size limit10 min
- 2025VM limits and big integers10 min
- 2027?CHIP-2025-031 min
- 4.1 The mechanism, not the constant
- BCH has replaced its difficulty algorithm three times, but those changes improved how ten minutes is maintained; they didn’t redefine it.
- 4.2 A coordination parameter
- Block size is balanced by each miner’s incentives, and a limit can be relaxed without breaking anything. The interval is necessarily a network-wide agreement, doesn’t change incentives, and going back would cost as much as the change.
- 4.3 0-conf, the answer we gave for years
- Anyone not following the forum will see that the network that answered “you don’t need to wait ten minutes” changed its protocol so as not to wait them. That reading costs 0-conf credibility exactly where it works.
- 4.4 Identity
- rnbrady, kanat, and Zander disapproved of the change with the same idea: “if it ain’t broke, don’t fix it.” A persistent social objection is itself a coordination cost.
A secondary observation: merchant adoption
In direct adoption work with merchants, in Argentina and elsewhere, block time has never been a real obstacle. Between users, transactions are accepted immediately, and tools that support 0-conf, such as prompt.cash, are used without trouble for online sales. Where 0-conf works, the ten-minute wait isn’t the obstacle.
What can be done without changing the interval
In almost every problem it cites, the CHIP mitigates without eliminating, and in most there are paths that don’t require touching a foundational constant.
| Problem | What the CHIP does | Alternative without changing the interval |
|---|---|---|
| Slow and variable first confirmation (swaps, gateways, multi-currency wallets) | Speeds it up | DSProofs with risk scoring and amount-tiered policies, already used by Bitgree and Thorswap |
| Multiple confirmations at exchanges | Gives predictability, not speed | Require confirmations by value and risk, not a fixed number |
| UTXO contention in DeFi | Shortens the wait; the collision remains | Order requests in the application, spread liquidity across several UTXOs, extend DSProofs to contracts |
| Hour-long-or-more blocks from hashrate drops | Shortens them | Study the difficulty adjustment’s response as a problem of its own |
| Locktime granularity | Improves it | Time-based locktime already exists |
| New users’ first impression | Indirectly | Wallets that show 0-conf payments as received; communication |
The alternatives don’t eliminate all waiting, but they reduce the cases that depend on block time. And if a third party doesn’t adopt them, nothing gets worse. If it doesn’t adapt to the CHIP, on the other hand, its 15 confirmations end up worth a tenth of the work without it knowing.
The request: not in 2027
My request is concrete: that CHIP-2025-03 not lock in on November 15, 2026, and that it be discussed again for a future upgrade, once the alternatives have been exhausted. To activate a change like this, the benefits should clearly outweigh the sum of the costs. At a minimum, before any activation:
- Quantify the activation costs with estimates from nodes, pools, exchanges, wallets, indexers, and DeFi, and with criteria to catch software that breaks silently.
- Deploy the SPV mitigations first (compact filters, batched sync, CHIP-2026-02) and verify them with real wallets.
- Evaluate specific solutions for DeFi contention and for services that require confirmations.
- Have a complete, tested implementation on chipnet with enough time, and real orphan-rate data.
- Achieve broad support, beyond the absence of technical objections on the forum.
This is not an isolated position. SW9 doesn’t think it necessary to push it for the next cycle if the implementation isn’t ready; Fernando Pelliccioni (Knuth) approves of the change but is neutral on the lock-in; 2qx approves “if implementation is ready in time”; albaDsl conditions his vote on Culianu signing off on the implementation. Postponing one cycle has a bounded, recoverable cost; activating without meeting these conditions, a permanent one.
Voices from the debate
Quotes from the Bitcoin Cash Research forum that raise reservations about the change, with the date each was written.
“We should solve the problem completely.”
“Without mempool synchronisation, it doesn’t matter if blocks are a minute or 10 minutes.”
“Add one minute blocks and SPV will die.”
“I disapprove mainly because the implementation is not ready, but I’m also wondering if we are giving up too much of our safety margin with 1-min blocks.”
“We need to distinguish between two things: speed and the perception of speed. […] Money requires clear, predictable, and stable rules.”
“To someone that has to implement this – it’s like a NUKE went off in the codebase. Everything got touched.”
The full essay
The essay develops each argument, answers the counterarguments, and cites its sources in 84 notes, almost all linking to the original post.
- What the CHIP is after
- The problem is real, but the change doesn’t eliminate it
- The costs
- Principles
- Merchant adoption
- What can be done without changing the interval
- The request: not in 2027
- Conclusion
Not yet, and not in 2027.
Solving each problem in the layer where it arises is slower and less flashy than changing a constant, but it attacks causes rather than symptoms. Anyone who shares these concerns can say so on the forum before November 15. Postponing the proposal doesn’t kill it: it gives it the time it needs to be done right.
Contact
If you find a mistake, outdated data, or an argument I didn’t consider, write to me.
Main sources
- CHIP-2025-03, current text (last edited 2026-10-24)
- CHIP discussion thread
- Statements of support and dissent thread
- rnbrady, Kraken and 15 confirmations (#150)
- JohnGalt, mempool and NFC (#149)
- rnbrady, solving the problem (#164)
- Tom Zander, SPV (2027 thread, #41)
- bitcoincashautist, batched sync (2027 thread, #48)
- Calin Culianu, complexity (#226, #230, #237, #243)
- Calin Culianu, support for the CHIP (#243)