Based on my current understanding of the benefits, risks, and ecosystem costs of the 1-minute block proposal, I am currently against implementing this CHIP. That does not mean I think 1-minute blocks are inherently bad. It means that, in my opinion, the demonstrated benefits do not sufficiently outweigh the risks, costs, and lost design space.
I want to say this in the same professional and courteous tone that BitcoinCashAutist has used throughout our conversations. The Faster Blocks CHIP is serious work, and BCA has been friendly, responsive, and willing to engage. I also want to be fair: overstating the benefits is a problem, but so is overstating the concerns. This is not an attempt to exaggerate the downside. It is an attempt to state the tradeoffs clearly.
The CHIP itself is more careful than some surrounding discussion. But opinions are formed as much in Telegram chats, podcasts, and informal debate as in the formal CHIP. If informal advocacy overstates the benefits, that matters too.
DeFi And Fractured Mempools
The strongest arguments for 1-minute blocks are confirmation latency and variance. I do not dispute them. First confirmations become faster. Long outlier waits become less painful. That is a real UX improvement, though there may be other solutions better suited to some of that pain, such as Imaginary Username’s Sunlight proposal. Sunlight sounds elegant and promising, but needs much more work before it can be considered.
Where I object most strongly is DeFi mempool divergence. I do not think this should be presented even as a meaningful partial solution, because that gives the impression that the improvement is significant. In the adversarial case, the worst case remains unacceptable, and the improvement is so marginal that it should not be counted as a DeFi mempool benefit.
Consider a Cauldron-style DeFi contract using shared or related micropool UTXOs. A user buys or sells, and a pool becomes slightly imbalanced. A bot in Europe sees the transaction first and immediately constructs a profitable rebalance transaction building on that state.
But the original transaction reaches Asia before the European bot’s follow-up does. A competing bot in Asia sees the same opportunity and creates its own rebalance transaction. Now Europe has one valid-looking DeFi chain, while Asia has another. Both may touch overlapping micropools. Both can be extended. Only one can eventually be mined.
This is not just a DeFi trader inconvenience. DeFi and payments are likely to become increasingly intertwined. Imagine a merchant who wants to accept PUSD. A customer’s wallet instantly swaps BCH for PUSD and pays the merchant in one “swipe.” Whether the merchant gets paid, or whether the transaction silently drops, now depends on whether the wallet was building on the UTXO branch that eventually wins.
The merchant and customer may even be on different fractured UTXO chains. The merchant may never see the payment, refuse to release the goods, and later get paid anyway when the customer’s branch wins. Or the merchant may see a payment, release goods, and later discover that the branch lost. These are not purely imaginary problems. They are a likely outcome of combining DeFi, payments, and fractured mempools.
The adversarial case is worse. An attacker can deliberately fracture the mempool after every block by sending different yet valid but conflicting transactions to different connected nodes. Random forwarding delay rules adhered to by nodes, intended to improve relay privacy, exacerbate this problem because they give a well-connected low-latency attacker more room to shape what different parts of the network see first.
Suppose the mempool diverges 5 seconds after each block. With 10-minute blocks, it is divergent for 9 minutes and 55 seconds, about 99% of the interval. With 1-minute blocks, it is divergent for 55 seconds, about 91% of the interval. That is mathematically better, but practically still terrible. A DeFi mempool that is divergent 91% of the time is not meaningfully improved.
As I put it in Telegram:
“Without mempool synchronisation, it doesn’t matter if blocks are a minute or 10 minutes”
This should not be read as “1-minute blocks literally do nothing.” They may reduce the window and sometimes the expected loot. But any real solution to this problem needs separate work: Sunlight, weak blocks, miner-visible ordering signals, better contract structures, or other coordination mechanisms. Any benefits those solutions provide should not be attributed too strongly to 1-minute blocks.
The NFC Offline Wallet Example
The second issue is low-bandwidth SPV. Classical SPV derives its security from validating the linked header chain. With 1-minute blocks, the number of headers grows roughly 10x. The CHIP uses a 15 Mbit/s mobile broadband assumption in its SPV bandwidth section. That may be reasonable for many mobile users, but it is too optimistic for NFC, LoRa-style wireless links, constrained hardware, censored networks, and degraded-connectivity environments.
The concrete design is an offline payer using a BCH SPV wallet, perhaps on a phone or eventually a card-like hardware wallet. The merchant terminal is online. During payment, the wallet communicates with the terminal over NFC. The terminal provides recent headers and filtered transaction data. The wallet updates its view, learns about incoming UTXOs since last use, and signs a payment.
With 10-minute blocks, one week of headers is about 1,008 headers, roughly 80 KB before overhead. That is plausibly small enough for tap-to-pay, it a user makes a payment one a week, he will need to ‘tap’ for about 1.5 seconds only. With 1-minute blocks, one week becomes about 10,080 headers, roughly 800 KB before overhead. Add protocol overhead, merkleblock data, and NFC’s real-world speed limits, and the UX changes from tap-to-pay to hold-to-pay for 15 seconds. The usecase breaks.
As I summarized it:
“With 10x more headers it now becomes not tap, but hold.”
This has not yet been built. But if block time decreases to 1 minute, this exact design may never be built. That is the “unseen” cost. Bastiat’s seen-and-unseen framing applies: the visible effect is faster confirmations; the invisible loss may be payment designs that never get attempted because the protocol made them impractical.
A BCH wallet that can remain offline, update through an online merchant terminal, and preserve classical SPV assumptions would be a valuable cash-like tool. It could work in metal buildings, festivals, rural areas, censored environments, or places where the merchant has connectivity but the customer does not. Losing that design space is a real cost to BCH.
SHV Does Not Fix The NFC Objection
SHV was brought forward in discussion as a possible solution for offline or low-bandwidth SPV use cases. It is valuable work and may significantly reduce header storage requirements. But it does not solve the NFC use case.
The NFC problem is bandwidth during the payment interaction, not long-term storage. SHV can help a wallet avoid keeping the entire header chain forever. It does not remove the need to verify that headers are actually connected to the valid chain if the wallet wants the same security model as classical SPV.
If a wallet accepts a loose or free-floating header commitment, it has taken a serious step back. The wallet may not know whether the presented tip actually connects to the real chain or whether it is being shown an isolated construction. A wallet with the full header history can verify linkage and accumulated proof-of-work from its trusted point forward. A wallet relying on a shortcut must introduce new assumptions.
Those assumptions may be acceptable for some wallets. But they are not the same thing as classical SPV with similar bandwidth, same security, and same UX.
Offline-Compatible Collateralized Transaction Chains
There may also be other ways to support degraded-connectivity payments that deserve exploration. One idea is a collateralized transaction-chain design.
The basic concept is that users create a sequence of transactions where each new transaction advances a counter. Script rules ensure that payment outputs can only be added or increased, never reduced or removed. Each transaction is still intended to be broadcast to the blockchain when possible.
While offline or disconnected, each party can hold the full chain of signed transactions back to inputs that are linked to confirmed mined blocks with Merkle proofs. Nodes or wallets can independently verify this because they have the block headers, can validate transaction structure, and can validate the Merkle proofs connecting those inputs to mined blocks.
The anti-cheat mechanism uses deterministic nonce reuse. The signing nonce is derived from the counter. If the payer behaves honestly, each counter value is used once, so each nonce is used once. If the payer tries to double-spend by creating two conflicting transactions at the same counter value, they must reuse the same deterministic nonce with the same key. Signing two different transactions with the same key and nonce exposes the private key.
That exposed key can be tied to collateral. For example, the payer could prove with a Merkle proof that they have 10 BCH locked in a collateral contract while making payments from a 1 BCH transaction chain. The same key that is exposed by cheating can be used to burn the 10 BCH collateral immediately. If the payer does not cheat, they can recover the collateral after a timeout, such as one month.
The collateral should not be paid to the merchant or miner, because that creates perverse incentives. It should be sent to an unspendable contract. The purpose is deterrence: cheating destroys the payer’s own collateral.
This design would need serious analysis, but the intuition is simple: if cheating on a 1 BCH transaction chain risks burning 10 BCH of collateral, playing fair becomes the rational choice.
This kind of design is also likely to operate over NFC or similarly constrained local links: two phones, a card and a terminal, or two local devices exchanging signed transaction chains, Merkle proofs, and recent headers. That means it faces the same low-bandwidth constraint as the NFC wallet example. With 10-minute blocks, header updates can remain small enough to fit into short local interactions. With 1-minute blocks, the 10x header growth can make these interactions practically impossible.
BCH has always been payments-first. If that is still the view of BCH today, then payment use cases like this, even if they do not exist yet, should not be sacrificed lightly. The fact that a design is still unbuilt does not mean it has no value. Sometimes the most important cost of a protocol change is the thing that never gets built afterward.
Ecosystem Cost
The CHIP says activation costs are “real but bounded.” I agree they are bounded. But I have not seen the costs quantified in a way that lets the community judge them properly.
A block-time change is not “just changing a variable.” Even if changing the block time in the future is literally changing one variable in BCHN, the infrastructure cost is still significant. Every ecosystem participant still has to understand, test, deploy, and support the change.
The cost includes node implementation and review, DAA and ABLA changes, locktime and coinbase maturity semantics, mining pool updates, exchange policy changes, wallet testing, explorer updates, indexer planning, documentation, testnet coordination, downstream library changes, reorg-handling review, deployment, and support.
The CHIP should include or solicit third-party estimates: how much time node teams need, how much time mining pools need, how much time wallets need, how much time explorers and indexers need, and how much coordination is required. Without that, the cost side is too easy to handwave.
The “See What Sticks” Problem
Another concern is the feeling of goalpost moving. When one benefit is challenged, another is offered: DeFi, MEV, cross-chain swaps, exchange UX, pool payouts, PR, locktime granularity, indexer memory, and so on.
Some of these benefits are real. But a consensus change should not feel like a bag of “maybe this argument will stick.” It should rest on concrete, quantified improvements that clearly outweigh quantified costs.
Ten small benefits can add up. But they should be measured, not accumulated rhetorically. If the strongest benefit is confirmation UX and variance reduction, then the proposal should stand mainly on that. If DeFi is not meaningfully improved in the adversarial case, it should not be counted as a material benefit.
Conclusion
My current position is that BCH should not implement this CHIP unless the benefits are shown to clearly and substantially outweigh the costs, risks, and lost design space.
1-minute blocks improve confirmation latency and reduce variance. Those benefits are real. DeFi mempool divergence should not be presented as a meaningful improvement, because the adversarial worst case remains unacceptable and the improvement is too small to rely on. SHV is useful for storage, but it does not preserve the offline NFC classical-SPV design without changing assumptions. The ecosystem cost is real, underquantified, and broader than a node-code change.
This is not opposition for its own sake. It is a request for honest accounting: be generous about real benefits, careful about overstated concerns, firm about overstated benefits, and mindful of the unseen things BCH may lose.
AI disclaimer. The arguments and thinking are 100% my own. A LLM was used to improve the readability and phrasing of the arguments.
