I did not say 1-conf.
I said 10x conf.
If Kraken takes 15 now, it will simply take 150 after the upgrade. That is what I meant.
I said “1-conf applications” to which you replied “Such applications (actually meaning: exchanges)”.
So just a misunderstanding but I still want to know who @bitcoincashautist is talking about when he says 'the main beneficiaries are 1-conf users…".
2 Likes
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!”
2 Likes
The problem is this framing:
- Speed : “Look how much better 1-conf at 1min is compared to 1-conf at 10min!”
- Security : “10-conf at 1min is just as secure as 1-conf at 10min.”
The benefit is actually that you get a sliding scale between $100 of security in 1-min, and $1000 of security in 10-minutes.
2 Likes
I agree with all of these.
But wait, if I agree, why are we arguing? 
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.
1 Like
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).
- Cross-chain swap services : Thorswap (minimum confirmation tier), Sideshift (above their 0-conf threshold).
- DeFi recovery : Cauldron and similar contracts whenever mempool divergence occurs.
- Multi-coin wallets : Coinomi (IIRC) and others that only display incoming transactions after first confirmation.
That’s off the top of my head. Would spending time investigating and producing an exhaustive list move the needle for your cost/benefit assessment?
From Bitgree:
What happens if a double-spend attempt is detected?
If a double-spend attempt appears during the 4-second waiting period, Bitgree simply displays the
1 confirmation requiredmessage, 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.
2 Likes
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.
3 Likes
Ooooooooooooft.
1 Like
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.
3 Likes
Case in point, currently waiting on block 957389 to get something done, it has been 115 minutes…
Not to mention high speed DeFi is currently broken as well. It is time for faster blocks IMO.
4 Likes
With faster blocks you’ll still see this error message. It will just clear faster.
We should solve the problem completely so the error is never encountered in the first place.
3 Likes
That works for me. With faster blocks so many annoying issues just solve themselves.
5 Likes
With Linux you will still see an error message when an app crashes. It will just recover faster than windows BSOD.
Obviously that’s not a fundamental improvement. We should solve the problem completely instead. Besides i never get BSOD personally. 
It’s different layers, the problem should be addressed at both layers.
1 Like
On bitcoin’s two “times”
This is just a follow up on comments in the thread about current wallet nLocktime practices. This is an exposition of height-based computing on bitcoin, and a potential reason it may have a renaissance in the future.
The bitcoin network was bootstrapped on it’s own timestamps (blocks). The height a transaction is committed to a block is the ultimate record, and most granular record, of the time it was spent. The standard Unix timestamps in a block header would never be used internally to resolve when a transaction was spent, because miners can fudge the time they write in a block header. All time logic started with heights as a base unit.
There is a Median Time Past (MTP) timestamp service on bitcoin, which is a derived aggregate byproduct of attested block unix timestamps. It’s created as a side effect of bitcoin’s primary height based timestamping service.
Since 2015, there have been two fairly powerful ways to program bitcoin on an absolute-basis (OP_CLV), or rolling basis (OP_CSV). Both of these OP_CODES came with functionality to enable using the primary timestamps (height) or the more ergonomic unix epoch timestamps (defined in BIP-113’s median time-past as endpoint).
The time op_code upgrades accommodated two ways of coding time on bitcoin. The pluralistic viewpoints about timestamps are as follows:
| Height (primary) | Unix Epoch (derived) |
|---|---|
| Blocks are timestamps | Unix epochs are timestamps |
| Blocks timestamp transactions | Block headers include timestamps |
| Blockchain is a timestamp service | Bitcoin has a timestamp service |
| Time is measured in blocks | Time is measured in seconds and minutes |
| We can know what height it is | We can know an aggregate time that has passed |
| Timelocks overflow after 500,000,000 | Timelocks overflow in 2108 |
Both of the above columns are valid statements about time and timestamps.
For the last ten years, it hasn’t really mattered which definition a time-locking system used. But there MAY be a strong case in the future for many types of financial instruments to use heights over MTP.
When blocks are slow, and the price is low, and things are going great, it can be really tempting to use the conventional definition of “timestamp” (MTP epoch) exclusively in defi contracts. And for contracts among known parties with signed spending paths, the derived epoch usage of the word time is totally fine.
However, if blocks are fast, and there are lots of contracts with MEV on the network with real money on the line, and if miners or institutional traders can find a way to game the MTP timestamps, they inevitability will begin to explore gaming MTP.
As a minority chain with low hashrate, it is somewhat trivial for a well capitalized actor to mine a block (or whole series of blocks), in the same way some people can DDoS all the major exchanges and somehow assure their trades clear. We can assume, as markets develop, if there is a pot of money to be had by gaming MTP that is greater than the cost of gaming MTP, then a well capitalized actor will take that money.
The detractors of decentralized finance seem to love financing market failures then decrying the failures they exploited. If, down the road, a well capitalized actor begins flash-mining chains of blocks to exploit mean time past, they can be expected to also turn around to decry that the system is unfair and rigged against normal users/investors.
The CashScript developer guide [archive] calls the signed and MEV paradigms the “Happy Case” and the “Adversarial Case” and categorically discourages contact developers from creating self-funded MEV-powered anyone-can-spend contracts. Much of the argument against using MEV on Bitcoin Cash is limited to the fact MEV is seen as bad on ETH. The potential, resilience and reliability of a system with eight billion potential executors is largely neglected. However, a number of contract systems have employed MEV and anyone-can-spend contracts with pretty great results.
If open markets using MEV systems with MTP timestamps begin to get gamed on a regular basis, there will be two obvious pathways to toward a fairer system. The slow path would be an upgrade the BIP-113 MTP definition through the CHIP process as a counter measure. Or alternatively, app devs can immediately begin deploying new contracts version using the OG non-MTP timestamps.
Depending on how far into the future an MTP contract system has been programed (decades/centuries), it may not be practical to revert to heights. If OP_CLV and OP_CSV continue to function as before with the old block heights, it may be somewhat maddening for new developers to convert by hand between new and old heights displayed in wallets and block explorers, especially if none of the tooling in the ecosystem supports it.
If block heights simply keep incrementing at CHIP activation, then future defi contract system developers will have to convert between new and old block heights by finding the intercept at the activation height and scaling from there. It’s a simple calculation about as difficult as converting from Fahrenheit to Celsius.
Two alternatives have been proposed to eliminate the need for that calculation. Blocks could increment by 0.1 after activation instead of a whole number; this keeps the old timescale. Or the block height could be increased 10X at activation and old blocks numbers (pre-activation) could be displayed with an extra zero in wallets or explorers that wanted that.
Regardless, apps that take the long view on the “Happy MEV” trail can keep showing a height-based block time equivalent calculated from the tick API. It would just be swell if all wallets and block explorers shared in the benefits of the long game by default.
As previously stated, I think the nomenclature the ecosystem ultimately uses for heights is NOT a blocking concern for this CHIP. All this is just to articulate the hidden value of continuing to accomidate the height-based times as a primary feature.
2 Likes
I object to this proposal because there is a fundamental trade-off that will make faster blocks harm SPV wallets.
To keep Bitcoin Cash a peer to peer electronic cash, we need to safe-guard the SPV wallet usecase, as that is the only known way to scale to billions of people, without introducing centralization and thus control. Lose the SPV usecase and 10 years from now we will hit scaling bottlenecks that become impossible to solve without sacrificing the decentralized nature of the coin.
An SPV wallet without central servers uses a simple concept, it downloads filtered blocks from a full node. Filtering a block implies the wallet sends a filter to the full node in order to allow the filtering to happen on the ‘server’. To not use server side filtering implies the wallet needing more bandwidth and CPU as the blocksize grows, and is thus not viable long term. Server side filtering is it.
A filter will essentially be a list of all addresses, but spending FROM an address should also work and spending FROM an address is not something a full node can do. As such the filter ALSO has a txid-outIndex combination.
So if I send a full node a filter that is viable at block 400, which then returns a transaction which deposits money in one of the addresses, I need to update the filter in order to see the transaction that spends that same money again in block 401. Lucky for us, the server will do this updating for us. So we can just batch block requests.
But there are still trade-offs, if you send 50000 requests because your imported wallet is that far behind, it won’t work. The node that is your server will see you as a DOS attack because a cheap request forces that node to be occupied for a while. Even if you can test this with a (patched) full node in private, it will fundamentally be a DOS attack and thus a real-life healthy network will need to stop that. Which means that the trade-off is smaller requests and incremental handling of data. Full nodes want to serve data, but not just to one abuser. Standard network rate limits.
There are other reasons why you can’t just ask thousands of blocks based on one filter too. For instance the filter is intentionally fuzzy. Which means you get matches that are not actually for you. This fact together with the server self-modifying the filter (see a couple of paragraphs back) will means more and more false positives.
Next to that, with a properly setup privacy wallet you want to avoid reusing addresses. As such a filter you send will get out of date too as it progresses in block-time. There are unlimited number of addresses on a HD wallet, which is great for privacy, but you can’t send a filter for all of them. Practically that won’t fit, but similarly it will mean that your wallet is not being very private.
The trade-off here is also, smaller batches work better.
When you ask for a single block, then the next block-filter will change a little based on the result of the first block. Transactions found that can be spent. Addresses used that can be removed from the filter. Addresses need to be added to not miss transactions.
The filter needs to constantly be adjusted. While you could just make the server do all that, which is largely what fulcrum allows, this is basically giving up on the concept of privacy.
So to repeat the base requirement of peer to peer money, no central servers, this means the filter concept as explained above is the only solution we have.
Latency
The fundamental requirement for private SPV wallets is thus inherently linear. As transactions come in the filter may need to be uploaded again. And if you already asked for 1000 blocks, and figure out at block 50 that that filter needs changing, then that will simply not be processed by the server until it finished those 1000 blocks.
What you need is bi-directional communication. You process the results of a block and decide if the server needs a new filter or not.
But this means you inherently add latency to the protocol. You can’t act on a (filtered) block until it arrived.
My Experience
The p2p network is filled with nodes where some are very slow (maybe some Pi with slow storage) and some are nice and fast. Similarly we have some that have low ping and some have high ping. And naturally the mobile network has extreme gradients in reliability and connectivity. So it is very hard to give numbers. And laboratory tests are very likely optimistic.
Tests I did gave about 100 blocks per second in 2025/2026.
This comes from code and logic written by me which is the result of learning and understanding the trade-offs I wrote in the long part above.
Can it be made faster?
Yes, but you’ll ask the server for more duplicate blocks at best, or get blocked at worst.
You may also just go with a very small number of addresses and reuse those which will similarly make things faster.
So the honest question is this:
Can SPV be made faster without sacrificing the peer to peer nature of our coin?
Answer is: Not by much.
Why then object to the proposal?
Because the fundamental problem is the speed of light, how long it take to ask a full node a question and the answer getting back to you. And that can’t be changed or innovated to be improved any time soon.
Making the block time shorter makes the sync similarly slower than today, on a fundamental level. It will basically make SPV too slow to be usable.
Which will lead the majority of people to prefer centralized solutions and that will kill decentralized peer to peer cash because eventually those centralized solutions will start to censor or worse.
Thanks for writing this. I’d like to take some time to digest it before responding, but didn’t want to “leave you on read” since I explicitly asked you to post this.
2 Likes
oh boy, perhaps my previous summary wasn’t “obvious” after all 
if u would, please allow me an opportunity to address your issues
point-by-point 
-
Your baseline is still BIP37
everything you describe – filter updates, false‑positive accumulation, the need for bi‑directional communication, the linear per‑block dependency – is true if and only if we assume a BIP37‑style bloom filter, where the client uploads a custom filter and the server scans blocks on its behalf
but that is NOT the only SPV model
BIP157/158 compact client‑side filtering eliminates every one of those problems: the filters are deterministic, pre‑computed, and downloaded in a batch with a single request there is NO filter to update, NO false‑positive drift, and NO per‑block handshake – this point was raised in my earlier post and you HAVE NOT addressed it!
-
Your own code contradicts the “fundamental limit” claim
bca’s test showed that by changing one line in your codebase (the batch size from 9 to 99), sync speed jumped from ~5 blocks/s to ~50 blocks/s.
that’s a 10X improvement with no protocol change – it clearly demonstrates that the slowness you experienced is, at least partly, a soft cap you yourself introduced; not an immutable property of the network
if a simple client tweak can produce such a gain, then the “speed of light” isn’t the bottleneck (at least not yet!) -
Batching and DoS
u worry that asking for many blocks at once is a DoS – but that concern only applies when each request forces the node to search – compact filter serving is static I/O; it’s no more a DoS than downloading block headers – even within BIP37, the test above shows that a node can handle a batch of 100 blocks without trouble – a real‑world BCH full node can certainly serve a range of filters without being overwhelmed -
DOGEcoin exists!
dogecoin has had 1‑minute blocks for its entire life, and its SPV wallets work fine – if 1‑minute blocks were an existential threat to light clients, we’d have seen it there – the fact that we haven’t strongly suggests the problem isn’t the block interval but the chosen SPV protocol and its implementation -
BCH can and SHOULD adopt compact filters
if the CHIP for faster blocks moves forward, it should simultaneously specify that nodes MUST support serving compact filters – this is an incremental, well‑tested upgrade that would give BCH light wallets a level of performance that completely sidesteps the BIP37 bottlenecks you’re describing – there’s NO reason to stay wedded to a 2013 protocol when a better one is already standard in the wider ecosystem
in short, YOUR conclusion that “faster blocks make SPV too slow” only holds if Bitcoin Cash:
- locks itself into BIP37 forever
- ignores measurable improvements from simple client‑side tuning
- disregards the existence of a lighter, more private protocol (BIP157/158) that is ALREADY LIVE!
- and pretend that a 1‑minute block time has never been tried successfully elsewhere
that’s NOT a convincing case for rejecting faster blocks on Bitcoin Cash. it’s a case for upgrading the light‑client infrastructure alongside the block interval – and that’s a goal imho EVERYONE should be encouraging 
looking forward to the benchmarks that will come out of the upcoming chipnets for this upgrade – that’s where these questions belong 
(btw, it took literally every bit of strength in my being NOT to mention even once just how geriatric your wallet infrastructure is – as that would’ve been unkind)
cheers!
4 Likes
In arguing with a 1 minute blocks skeptic, I have hit on this new framing.
I think this is going to significantly change the debate. It instantly demonstrates how 10 minute blocks is simply an argument for the status quo, it has no empirical basis. When said like this, it becomes much more difficult for skeptics to hide behind a lack of better solutions.
It is beholden on the CHIP proposers to demonstrate an overwhelmingly strong case to move. The default is the status quo, and that’s for very good reason. But in this case, the status quo is a significant liability, and nobody has produced any data to prove it isn’t.
2 Likes