The meta is the most important part of your post, so I’ll address that first. I’ll address the specific technical points (DeFi mempool, NFC, SHV) further down.
What is the goal, though? The CHIP’s goal is to deliver faster blocks. That goal isn’t being moved, everything being done is being done in service of that goal. The list of benefits isn’t a list of goals. It’s just that: a list of benefits. Ultimate motivation is to make BCH thrive and be competitive so nobody will want to consider anything else, that’s the over-arching goal. Become better for existing users, and attract new users. That’s the goal. Of course, we shouldn’t sacrifice core properties in pursuit of that goal, but this CHIP isn’t sacrificing any promise of “Bitcoin: A Peer-to-Peer Electronic Cash System”; it is helping advance its mission:
What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.
What is the purpose of the CHIP process? To gather consensus for a change. How do you do that? By convincing people. The “see what sticks” framing is actually a feature of this process, not a bug, which I tried to explain to you on Telegram.
The benefits are descriptions of how different users experience the change. The aggregate benefit is the sum of those individual experiences. For whom is the network? For users, and there are various kinds of users. If you use the network in a particular way, you will benefit from some aspect of faster blocks more than some other. CHIP has to convince not just one particular user, but has to convince the vast majority, who will have differing subjective views on what is important. Average user doesn’t exist. Users with specific pain points and experiences and individual cost/reward assessments exist. So, it’s just the nature of this change that the list of benefits is long and varying, and importance of any 1 benefit to any CHIP reader will vary, so how do I find what’s most important to any 1 individual? Iterate through the list:
- to a pool runner, payout frequency will be the best benefit
- to a cross-chain DEX trader, faster swaps will be the best benefit
- to a smart contract developer, finer locktime granularity will be the best benefit
- to an indexer developer, lower memory requirements will be the best benefit
- to a cash user, faster checkout will be the best benefit (it’s not the user’s choice: whenever the counter-party falls back from 0-conf to 1-conf, the user has to bear the wait)
If it’s not a good enough benefit for you, it may be a good enough benefit for someone else, which is why the meta points towards this CHIP’s activation, because almost everyone can find a reason to want it for themselves.
The iterative process of finding which benefit lands with a given reader can feel like goalpost moving from the outside, but it isn’t. Others worked through the list, found their benefit, and decided to support the CHIP. They’re now happily watching it progress. From what I’ve observed, those in opposition usually won’t even be negatively impacted themselves. They’re advocating for some third party who may or may not have to bear a cost, or speculating on how others will react. If third parties would be meaningfully harmed, the CHIP has been public for over a year; reasonable outreach has happened through forums, podcasts, and adjacent channels. Most actual stakeholders (node teams, pool operators, exchanges, wallet developers) are reading or at least aware. Silence isn’t proof of harm-free deployment, but it is a signal that the loudest concerns are coming from advocates of theoretical third parties rather than the parties themselves.
There is an asymmetry here worth noting: supporters typically advocate for first-party benefits (their own) in their own name, while opposition often advocates for third-party costs they themselves won’t bear. If the CHIP activates, much of the concern about hypothetical third-party problems will likely fade, because for many of those third parties it isn’t as big a deal as feared, and many of them will themselves want the benefits enough to absorb the cost.
And: most of the costs, risks, and benefits sections in the CHIP exist because reviewers asked for them. “What about exchanges?” “What about DeFi?” “What about the mempool fee decay?” “What about smaller pools?” Each section was added in response to questions raised here or in adjacent forums, including by you. That’s responding to reviewer requests for more detail on impact. If the answer to every reviewer question that prompts a new benefit section is “this expanded list looks like see-what-sticks”, then the CHIP process is in a double-bind: don’t address concerns and be accused of dismissing them, or address them and be accused of rhetorical accumulation.
This is a subjective cost-benefit judgment. For some users, even a single benefit on the list outweighs the cost. Your judgement isn’t wrong for you, but it isn’t authoritative for everyone else either; the CHIP process aggregates many such individual judgments.
For whom is it a problem? Each reader can judge benefits against their own costs. Let me give a concrete example.
Consider the mempool divergence case at today’s actual divergence rates. We don’t have a precise number, but anecdotal reports suggest divergence happens occasionally, often enough to be noticed, but not so often that it deters users from continuing to use DeFi. Those users today wait 10-30 minutes when caught by a divergence event. With 1-minute blocks, the same users would wait 1-3 minutes. That is a real, present-day UX gain for real, present-day users. Would they agree this benefit is overstated?
Your argument shifts the comparison to a hypothetical future state where divergence is 91% of the interval and faster blocks won’t materially help. That future may or may not materialize. But even if it does, it doesn’t erase the gain today’s users get under today’s conditions. And if divergence stays at current levels rather than climbing to the worst-case 91%, the faster-recovery benefit is large, not marginal.
It’s two different things being weighed:
- present users hit by present-day divergence will see their recovery wait drop from 10-30 minutes to 1-3 minutes; this is real, measurable, and happening now. Anyone who’s used Cauldron enough has experienced it, waited out a block, and continued;
- whether some future state of permanent severe divergence emerges, and whether 1-minute blocks help in that state, is conjecture about a future that may never arrive.
You can argue the future case matters more, but you can’t argue the present case isn’t a real benefit to real users today.
Bastiat’s seen-and-unseen framing actually cuts the other way here: the unseen cost of not upgrading is the users we lose to other networks because they care about block time, and the daily friction borne by existing users while waiting through the variance tail. The hypothetical offline NFC card doesn’t exist; there are zero users impacted by its non-existence, paying zero real cost today. The currently-frustrated user is real and present.
The CHIP process doesn’t require quantifying stakeholder costs centrally; it requires asking stakeholders directly. That’s how every past upgrade was assessed. We poll node teams, mining pools, exchanges, wallet developers, explorers, and indexers with a simple question: “Do you support this upgrade?” Their answer is the cost assessment, internalized by the party who actually pays the cost.
The quantification you’re asking for, “X hours for BCHN, Y hours for explorers”, isn’t realistically gatherable because every team’s situation differs and most don’t track activation work in those units. What we can gather, and what actually matters for activation, is the yes/no/indifferent signal from each stakeholder. If most say yes, the community loses nothing. If many say no, that’s a real signal that warrants reconsidering. We’ll gather these signals through CHIP outreach as the proposal matures.
There’s also an asymmetry in cost between us. You can ask for arbitrary additional research, but I’m the one paying the time cost of producing it. I’m happy to do so when the request is well-scoped and likely to change minds; I’m cautious when the request is open-ended and the result will probably just generate further requests.
Each of your technical objections deserves a response. The common thread: they all compare a hypothetical future cost (DeFi divergence at 91%, unbuilt NFC card, unbuilt offline-collateral design) against a real present-day benefit (faster recovery for current Cauldron users, faster checkout for everyone, reduced variance for 1-conf services). Hypothetical costs deserve consideration but cannot outweigh measurable present-day gains for measurable present-day users.
DeFi And Fractured Mempools
It needs a lot of work, and there’s no guarantee it can actually be implemented while preserving scalability. How many sets of partial-PoW block templates can a node with constrained resources juggle between blocks? My intuition is that the number is limited, and if so, then the time interval between shares will be some 1/K of target block time, which means that faster blocks mean faster shares.
Another question is: does it even help address fracture, or does it just make it publicly known ahead of a block? Sometimes it may help converge, but sometimes stubborn miners will be fighting it out and maintain fracture, so users whose TXs are under contention will have to await the next block to see who won. It’s better to have to wait 1-3 minutes than 10-30 minutes. I keep stressing this: 1-conf is the fail-over, the fallback, not the default, and so no matter what you do: faster blocks make it work better at least by smoothing out the edge cases.
Ask anyone who’s experienced a Cauldron divergence delay first-hand whether dropping recovery from 10-30 minutes to 1-3 minutes feels marginal.
And faster blocks help here! By the time the user reaches merchant checkout, one of two things has happened: either the DeFi chain got mined (the user pays the merchant from a confirmed UTXO with DSP score 1, merchant accepts 0-conf), or the DeFi chain failed and the user falls back to their pre-DeFi confirmed UTXO (also DSP score 1, merchant accepts 0-conf). Either way, the merchant gets a clean 0-conf payment. With 10-minute blocks, the DeFi chain is likely still unconfirmed at checkout time, DSP score is 0, merchant requires 1-conf, and now the user is stuck waiting and uncertain whether the underlying DeFi chain will get mined at all.
There is no “the” mempool. Mempools are node-local and made of individual transactions - and those can diverge, not the mempool as a whole. If an attacker fractures his own spends it doesn’t affect your spends unless you happen to build on the attacker’s spend. If one transaction diverges between two nodes’ mempools, the other transactions do not. All the TXs in set intersection go through, unaffected by local divergences. That’s the beauty of the UTXO model! One divergent TX doesn’t diverge the whole mempool: it’s contained to just that 1 TX and any descendants of it.
But even if Cauldron design can’t be salvaged, other DEX designs will benefit from faster blocks. Consider Jason’s Jedex:
Parallel Order Submission
The system maintains multiple Unspent Transaction Outputs (UTXOs) to accept orders from many users in parallel, and transactions are ordered within these “threads” by users rather than miners or well-connected nodes; this reduces the impact of market manipulation like frontrunning, and could offer better pricing and more consistent experiences for users.
In this model, DEX activity flows smoothly between blocks because users order their own transactions within their thread; UTXO contention is avoided by design. Transitioning from DEX activity to a 0-conf payment still requires waiting for a block, which merges all users’ threads into the main thread. Faster blocks shrink that wait directly.
The NFC Offline Wallet Example
The NFC offline-wallet scenario is a legitimate design constraint to consider, but several of its premises deserve examination before concluding that 1-minute blocks foreclose the design.
First, NFC bandwidth is already a serious constraint even at 10-minute blocks. Speeds are 106 to 424 kbit/s, translating to roughly 165 to 662 headers per second. Syncing one week of headers (1,008 headers at 10-min blocks, ~80 KB) already takes ~1.5 seconds at optimistic NFC throughput; in practice, NFC transfers are fragile (mid-sync card movement breaks them), so even the 10-minute case isn’t a smooth tap-to-pay today. This isn’t a 1-minute-blocks problem specifically; it’s a fundamental NFC bandwidth constraint that any header-sync-over-NFC design has to confront.
Beyond headers, the wallet also needs to sync UTXOs and their SPV proofs. If incoming UTXOs are the result of bigger transactions and the wallet has accumulated several between syncs, the proof data dominates the transfer; this is invariant of block cadence and depends entirely on the user’s send/receive pattern.
Second, the offline payer design assumes the card needs classical-SPV security, which the payer role doesn’t actually require (see the SHV section below for the full argument). On the other hand, if the recipient is offline (e.g. an offline vending machine), then they could be fooled into releasing goods for an invalid payment. But that’s a different scenario from the one being discussed, and a vending machine is powered, so it can sync via something faster than NFC like Bluetooth.
Product development for wallets and POS systems is driven by businesses. Do you really believe any business would go through the pains of fiddly NFC to transfer headers when there are many better alternatives? They could instead build an oracle for their POS system that signs a Merkle root commitment over recent headers (a fixed-size payload of ~100 bytes, including signature and 32-byte root), and invite other businesses to join the federation.
SHV Doesn’t Address The NFC Problem, But Neither Does The NFC Problem Need It
You’re right that SHV doesn’t give the same security model as classical SPV. With a linear header chain, the deeper a transaction is buried, the more PoW protects it; the security gradient is continuous. With an MMR commitment, all history past the commitment depth is protected by the PoW burying the commitment, which flattens that gradient.
But the real question is whether the NFC payment scenario actually needs classical-SPV security at all.
The card’s job is to sign valid spends of UTXOs that the merchant terminal claims are spendable. If the terminal lies about UTXO state, the card signs a transaction that never confirms. The failure mode is “no payment”, not “stolen funds from the card”. The card doesn’t need to independently verify the chain’s full PoW history to be safe in this role; it just needs the terminal to tell it which UTXOs exist, and the merchant’s network connection is the natural source of that information.
For the inverse direction (the offline recipient, e.g. a vending machine), the recipient bears the fraud risk. There are well-known designs to bound that risk: small balances, replenishment cycles, fraud-loss budgets. None of these require classical SPV on the recipient side.
So the NFC bandwidth concern presupposes a security model (classical SPV inside the card) that the payment scenarios being discussed don’t actually need. Once you drop that presupposition, the 10x header growth concern dissolves. SHV, merchant-signed oracles, and other compression mechanisms are available for designs that do want stronger SPV-style guarantees, but for tap-to-pay scenarios the foundational requirement isn’t there.
Offline-Compatible Collateralized Transaction Chains
I pondered this idea, too. I don’t think it works if 2 parties are offline, because then you run into state management issues: there’s no way to check you’re not the target of a double spend. When a vending machine is offline, it would have some loss rate and recover when some honest user stops by. All these schemes rely on at least some trust in people who interact with the offline device. I don’t think you can make it work when offline devices interact directly with each other. Perhaps with a secure enclave managing state handover, the trusted chip could enforce honesty, but that’s a different design.
Powered devices have faster local-link options than NFC (Bluetooth, Wi-Fi Direct, USB). The NFC-as-only-channel framing assumes the constraint that powered devices don’t have. And even if the constraint did apply, the same argument as above: how likely is this design to materialize at all, with any block time?
Yes, but not offline-payments-first.
How do we measure value? In a market context, revenue is the clearest signal. No users, no transactions, no revenue, no demonstrated value. We can argue hypotheticals all day, but revenue is the most concrete proof of value. And current revenue streams will benefit from faster blocks, while unbuilt hypotheticals neither benefit nor suffer.
Cuts both ways. The cost of not changing is the revenue and users that never come over to BCH because BCH stayed slow while others got faster. We can’t measure that cost either, but it’s just as real as the unbuilt NFC card.
