They did not, although now they pass target block time as argument to relevant functions so their next switch will be easier, too. Still, it will have a few more places to edit compared to our hypothetical 2nd change.
Youâre making this look more complicated than it is. Look, itâs just a nice little class that exposes uint64_t HeightToTick(uint64_t height) and this ticks object that contains the block time change schedule becomes part of blockchain config. You update the schedule/config in some future upgrade, all the stuff that calls HeightToTick adapts automagically.
Ticks are intended to make implementation easier, not harder. My PoC ticks.h/.cpp is a well-contained 130 LOC class, thatâs all. Then other parts of code become easier to manage.
Completely wrong. Zcash implementation had to touch all those lines just the same and it turns out that itâs a +813 / -429 diff. My ticks would add about +130.
Software, especially software like Bitcoin(Cash) is really complicated. Have you already implemented it?
Are you mentally prepared for all the unforseen consequences?
What I am saying is, before somebody actually does it, we can not know.
No offense intended, but I would trust an opinion of an active maintainer that actually can imagine the needed code in his mind right now (roughly), much more than I trust your estimate.
I literally just told you how I know. Zcash is a code fork of Bitcoin, a block time change in Zcash will touch almost exact same parts of code as it will touch on BCH. And their touching resulted in +813 / -429 diff which gives us a pretty good idea.
And by now my skills have grown enough that I can implement a whole new system in 5k LOCs (simple header verification served via P2P). I still frustrate Calin sometimes, but I can get things done, too. I also did a fairly complicated refactoring of some RPC functions (+282/-182), and added new features, too (+295/-227).
This is all to say, maybe I know what Iâm talking about because over time I got more and more involved with BCHN code, and hearing stuff like âespecially software like Bitcoin(Cash) is really complicatedâ is a little frustrating, because of course it looks complicated to you who are not working on it. Maybe itâs not so complicated to others, you know?
Partially, I just wanted to experiment with adding ticks to RPC so I did that part, and I implemented abla_ticks, too, by modifying Calinâs BCHN ABLA implementation. The diff to update ABLA with ticks is just +43 / -19 lines.
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.
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.
Iâm not aware of any exchanges that accept 1-conf. Can you give examples? I know Kraken requires 15 confirmations, and some others 11 due to the rollling checkoint.
I donât know how many times people canât understand this point.
We are NOT trying to trick exchanges into 10x lower confirmations.
MOST exchanges will probably 10x the confirmations. Thatâs fine.
SOME exchanges perhaps wonât, or will find the increased granularity means they can have e.g. 15x 1 min confs instead of 2x 10 min. Therefore, some amount of exchanges will get a speed up, which is a nice bonus as and where it happens.
EVEN IF no exchange lowers their confs, users benefit from the faster â1st confâ and âloading bar effectâ in watching their coins hit the exchange.
All the other benefits of the CHIP apply regardless of this specific case of exchanges adjusting their confirmations. Even if every exchange adjusts their confirmations 10x, the CHIP is still highly beneficial to the ecosystem as a whole - but people get quite lost or fixated on this one specific point for some reason.
Honestly I think this deserves its own section in the CHIP @bitcoincashautist because it has to be explained over and over and over again. I think there is already stuff about exchange behaviour, but not that explains it this directly and rigorously.
Yes there is this section: ac-0353f40e / Faster Blocks for Bitcoin Cash ¡ GitLab but it doesnât clearly and in one single place refute this constant appeal to âbut 1 minute blocks donât make exchange deposits faster because exchanges will 10x the confs!â
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.
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.
Nobody wants to be a 1-conf user, everyone wants to be a 0-conf user, but once youâre at checkout itâs not up to you, itâs up to your counter-party. Any 0-conf user becomes a 1-conf user when context demands it: mempool divergence resolution (Cauldron case), counter-party security policy (payment processors), or cross-chain swap thresholds (Thorswap, Sideshift above certain amounts).
Yes, e.g. Thorswap has a sliding scale: low-value swaps and high-clout swappers get the minimum confirmation requirement (typically 1-conf), while higher-value/lower-clout swaps require more. AFAIK Sideshift.ai accepts 0-conf for smaller payments and bumps to 1-conf above some threshold. Faster blocks turn this into a finer scale.
Why is speed claim a problem? It has real UX impact. Whenever youâre downgraded from 0-conf to 1-conf you benefit from faster 1-conf.
Nobody is making the security argument as a universal frame. What Iâm saying is that there are cases where the recipient just requires any non-zero amount of PoW, and even a lower-difficulty 1-conf satisfies that. Sometimes itâs not about security, itâs about sync.
Mempool 0-conf is async (different nodes may see different state); 1-conf is a sync event (everyone agrees on what got included), with only a small tail probability of reorg. I think some multi-coin wallets donât even bother with mempool transactions, they just wait for a block before showing incoming TXs.
Different users and different use cases sit at different points on that scale, which is why I describe the upgrade differently depending on context: 1-conf users (no scaling, pure speed gain), n-conf users (worst-case 10x scaling, same wall-clock security, but with finer-grained policy options), and sliding-scale users (genuinely better fit between transaction value and required confirmations).
Payment processors : BitPay, Coinsbee, Bitgree (Bitgree uses DSPs, but DSP-score-0 or DSP-fired transactions fall back to 1-conf).
If a double-spend attempt appears during the 4-second waiting period, Bitgree simply displays the 1 confirmation required message, just as it did before.
The same applies if double-spend proofs are not applicable to a specific transaction due to technical criteria, although this only happens in very few cases.
This perfectly describes the unease people are expressing. The author here states clearly that the goal of the proposal is the goal of the proposal.
So when people asked about goals before they got explanations like âit will help with exchangesâ, but weâve reached the point where none of the goals that make sense actually are significantly improved by the proposal. So we get to the naked truth. There is no goal other than the change itself.
Every proposal has to actually solve an actually problem for actual people. Or support a new usecase for actual users. If you look back at the activated list of proposals youâll find a âMotivationâ chapter or similar.
This proposal feels weird since it is made by someone that behaves like a politician being paid to make new laws: the connection to the people is lost.
The goalâs right there: Bitgreeâs 1-conf fallback, Thorswapâs tiers, real services today. Argue itâs too small if you want, thatâs fair. But âtoo small for meâ isnât âno goal.â Wanting faster UX is a legitimate goal, a goal many people share.
âthe peopleâ wanted faster blocks since at least 2015, and they were always being shut down by folks like you, saying it canât be done, and saying so without any real analysis; and nobody wanted to do the thankless work of working through all the technical obstacles.
Gavin, Roger, Jihan, they all wanted faster blocks, are they not people to you? Then all the users who got excited about the 1-min blocks and want to have the change. Anyone whoâs ever had to wait 20 minutes for a block wants it. Are they not people to you?
Now that the CHIP has demonstrated there arenât really any insurmountable technical obstacles, youâve moved to attacking the CHIPâs meta to obstruct it, because you have nothing else. Every time I defeated one obstacle you put up another: orphan rates, header growth, SPV, security, the CHIP worked through all of them. You also try to negate the benefits, but nobodyâs buying it. Everyone here has waited on a block. They know what the benefit is. Now you have nothing left but the meta.
Before this CHIP, the best proposal for faster blocks (2 minutes) was Prof. Liu Changyongâs 2019 work: âProposal to shorten the block time of BCHâ. He did some really good work there but it wasnât enough at the time. One of my favorite parts is his way of addressing the âthere are no benefitsâ complaint:
(2) Is there any essential difference between 2 minutes and 10 minutes?
Worry: Regardless of 10 minutes or 2 minutes, the user needs to wait for confirmation. There is no essential difference. Also Considering the contingency of the block, it usually takes 10 minutes to actually wait for one confirmation if shortening to 2 minutes.
Answer:
Anyone can easily experience a significant difference between waiting for 10 minutes and 2 minutes. Please close your eyes and count to 120, then to 480.
This is a great point. We do need to find a way of explaining it that makes the reality clear - that faster blocks is sometimes a benefit to speed and sometimes a benefit to security, and essentially never a downgrade on either⌠but there are still cases which can be found that donât show much benefit which is where detractors tend to get caught up through the mutual exclusion fallacy.
A âsliding scaleâ is a good way of putting it, well said. Iâll think on that some more, might need to explain it like that from now on.
