Can you please explain how 1-minute blocks kill SPV?
3 Likes
And why didn’t they kill BIP-37 SPV on Doge?
4 Likes
The basic concept of SPV is that it completely separates the transaction load from the wallet. The SPV wallet won’t really notice if the block is 10KB or 10GB. The SPV wallet gets the same data in either case. This is also explained in the whitepaper and it is the main reason why it is touted as the way to scale to world size.
The way to update is to ask a full node to please search block N for transactions matching my filter.
Repeat until you’re at the tip.
This today is already slow, asking a full node for 50-thousand blocks per year takes time, regardless of how fast that full node is. If you catch up a wallet that’s been offline for a month you’re looking at well over 4K blocks.
Now, today the blocks are small. Tiny, honestly. Which shows that the slowness you have today is due to overhead, not due to the full node doing actual work doing that search.
When you do a 10x of that work, the already slow system will become unusable. Suddenly you see half a million blocks per year. Which takes forever to ask each in order.
The obvious idea of just asking them faster, to send 1000 block requests in one go and wait for the answer, is easy to see that it will quickly fail. I mean, send 1000 search requests to google in one second and see what happens. The result is that you can ask, buy you’ll not get those search requests handled. At least when the search doesn’t take 1 millisecond.
The basic idea of SPV is to separate the load of the network from the load of the single wallet and that exists because that is the only way to scale. More people using it doesn’t result in more work on each individual wallet. Doing a 10x will naively make you think that this basic principle isn’t changed. We just put 10 times the work on the wallet, not a million times as we want to grow our community to a million times. But that simple logic doesn’t take into account that this overhead exists where you honestly need to patiently wait for the server to answer your question before you ask your next, since it will just experience you as a DDOS vector otherwise.
The bottom line is that a bloom system works because the exposed data load is just the headers and it is balanced very well with overheads and low number of request.
Clicking on a link on my 5G phone that downloads with 60MB/sec doesn’t open me a website any faster than on a 5 year old phone. Speed of light isn’t negotiable.
Tl;Dr: the faster blocks will make the SPV wallet slower to a pace that is going to make it impossible to compete. We’re at the edge of such today. Making it 10 times as slow is a death sentence.
Ask the full node for a range of blocks, not one-by-one.
3 Likes
Is there any codebase that currently exists where we can get real benchmarks on this? Seems to make sense in theory but I suspect this is merely an algorithmic challenge in terms of block lookup, not an actual scaling bottleneck.
4 Likes
it’s bs strawman “arguments” like this that hold back progress, smh – and i’d really LOVE to see 1min (or even 2min) BCH blocks; so i’d like to point out “the obvious”
tl;dr – you’re criticizing a protocol (BIP37) that is already being superseded by a design that specifically solves the batch‑request and privacy problems 
main points of bips 157 & 158:
- the full node pre‑computes a small (~20 KB) deterministic filter for each block; essentially a compressed list of all relevant scripts
- the wallet can request ranges of these filters in a single request, download them in one go, and scan them locally to decide which blocks it actually needs
- there’s no “search n, wait, search n+1” nonsense; the wallet just says “give me filters for blocks [500 000–520 000]” and processes the stream at its own pace
the overhead you identified, round‑trips multiplied by block count, nearly disappears!
so for example, even with half a million blocks a year (a 1‑minute block time), syncing a month’s catch‑up would involve downloading ~800MB of filters – a modern 5G connection handles that in under a minute, and the local scan can run in parallel and entirely OFFLINE!
bottom line, imho, YOUR wallet is just too f’n slow – so please don’t blame the network for advancing past your limited capabilities 
cheers!
5 Likes
It can do the same with BIP-37. Wallet can request multiple merkleblocks in a single request, node responds with a stream of responses, no round-trips for each response. So, increasing number of requests in the batch speeds things up.
Yes. I tested with Tom’s codebase, he can get a ~10x speed-up by changing 1 lline of code, which he refuses to do.
I changed this one line from 9 to 99 and recompiled:
m_merkleDownloadTo = std::min(m_merkleDownloadFrom + 99,
And who could’ve guessed, the wallet jumped from syncing about 5 blocks / second to 50 blocks / second!
Can’t believe that this simple speedup eluded Tom for 15 years 
When I told him about it in a Telegram group chat, this was the reaction:
[5/21/26 7:37 PM] bitcoincashautist in reply to Tom Zander:
> The wallet wants the server to examine "all transactions since...
just change this one line of code man, change this number from 10 to 100
https://codeberg.org/Flowee/thehub/src/branch/master/libs/p2p/Peer.cpp#L373
[5/21/26 7:38 PM] Tom Zander in reply to bitcoincashautist:
> just change this one line of code man,...
Can you please not be so super amazingly denigrating to someone that actually built that code for years and has been building tech in this space for more than 10 years.
"just change the number, man!".
It is not helpful.
Anyone can change the same line, recompile, and test for themselves.
“SPV can’t handle 1‑minute blocks” claim is based on a self‑imposed bottleneck, not a protocol limit.
4 Likes
First principles and a decade of experience, with a significant amount of experimentation and testing on figuring out how hard you can push one lever before another starts biting you in the ass.
It is a tad more than theory in that way.
What say you to this, @tom? The chat log that BCA posted doesn’t explain what’s wrong with that solution.
2 Likes
The longer post I wrote yesterday addresses that in multiple ways.
But the idea is basically identical what I started out with in the p2p lib on flowee, I had it in place for a couple of months until it turned out it was causing more problems than it solved. Which is why in around 2021 I had to change it to what you see now.
Tl;Dr: Was the first idea of mine too. Turned out to be naive and had to improve it to balance the whole better.
I think I must have missed something in that post. Do you think you could do a solid writeup in the actual CHIP thread expressing your concerns, purely from a technical perspective, without inserting opinions about the metadiscussion?
There are a few things in the CHIP thread that @rnbrady had mentioned as well regarding SPV. I intuitively share some of those concerns in regards to SPV over NFC, but as I reason through it I’m not sure if it’s a real problem in the modern reality where tech like Starlink and ubiquitous 5G connectivity exist.
I would appreciate your input there considering you seem to have concerns of a similar class. I’d very much like to evaluate the proposal on concrete, measurable technical merit.
2 Likes
Don’t confuse bandwidth and latency. It is the latency that gets you.
Grandstanding with 15 yeears of experience, and you still didn’t hear about batching? There is no fundamental reason why 1-min blocks should hamper SPV. Even P2P protocol as-is has enough batching support, which you tried to handwave yet again. Maybe you could use your years of experience to come up with even better P2P protocol for SPV wallets, like merkleblockbatch response.
PS interesting that your commit doesn’t give any reason for changing the number from 100 to 9. In 2021 you made your wallet 10x slower for no reason.
Fix merkleblock download as bloom filters change.
In HD wallets we get an issue where not-yet-generated keys are needed in the merkle-block request and we notice this as a chunk of blocks is being downloaded. This is solved with some extra code. Also avoid re-uploading the bloom filter during initial sync.
https://codeberg.org/Flowee/thehub/commit/701698d6e12fc0e34a73bf136f0845cfcdb17337
3 Likes
bwahahaha 
good luck with that 
2 Likes
I’m struggling to make the connection. I re-read your long post again and the tl;dr is what you just said here, but I’m failing to see where latency becomes a factor for SPV with 1-minute blocks. If you could make it crystal-clear for me, I would appreciate it… sorry.
Why would we round-trip a request for each individual block/address/filter? Why not just do a single request, which would mean latency is the same regardless of payload size?
Edit: I see you did write in the Fablous thread, so I will read that and continue there.
4 Likes
We now have just over 90 days until the November 15, 2026 lock-in date. My, how time flies!
To my knowledge, these are the CHIPs that are being realistically discussed for the 2027 upgrade cycle:
- CHIP-2025-05 Native Elliptic Curve Arithmetic Operations
- Chip-2026-06: op_sighash
- CHIP-2025-03 Faster Blocks for Bitcoin Cash
Per the suggested CHIP schedule, any serious and non-controversial contender should now be starting to seek full node implementation and preliminary stakeholder statements.
I am not aware of unanimous consensus for any of these three proposals, nor unanimous rejection. I think that EC ops and OP_SIGHASH could make it into this upgrade cycle with a strong proponent to carry it across the finish line.
I personally think that Faster Blocks needs more time to simmer. There are clear benefits, but I do not think the problem space is fully explored, nor do I think the community at large has had enough time to fully digest the proposal.
Importantly, I am not expressing this opinion as a “pro-ossification” signal. I just think there needs to be more time, discussion, and evaluation of alternatives. Imagine if we settled on OP_GROUP or PMv3 and never got CashTokens 
2 Likes
If Faster blocks (or any of the others) sit a year, then keep in mind that will mean they won’t activate until May 2028 at the earliest, which is the far flung reaches of spacetime in today’s world.
But also, I guess it’ll come around faster than we expect like always.
I do hope we can get to a solid lock in, but you’re right it’s getting down to it and I do still see some debate and people that are ambivalent rather than excited.
1 Like
Which part of the problem space do you think is underexplored? Nice thing is it doesn’t conflict with other improvements (Tailstorm, Sunlight, w/e, they can all work fine, or even better, with faster base blocks). Unlike Group vs CashTokens we’re not really building a new subsystem, we’re just tuning the parameter of an existing system, so it doesn’t really conflict with any hypothetical future thing.
Which part of the community do you think didn’t yet digest it? I think it’s pretty much digested, what new thing could surface? I think postponing would just create opportunity for detractors to try throw a wrench.
You will never get unanimous. Best we can do is some loose and overwhelming agreement. There will always be those who disagree, can’t hold the horse just for them. Activation is the ultimate test of how well we built and estimated the support, every activation is a vote of confidence.
3 Likes
I don’t think we’ve adequately explored the impact to SPV; we’ve only discussed potential mitigations but haven’t actually assessed viability of those mitigations from a practical/implementation standpoint.
I’m not confident that there are not still unknowns to explore. That’s part of what I mean by digestion. The CHIP as written is indeed quite thorough, and by no means do I want to discount that or claim that the work has not been valuable.
I’m hesitant to strongly endorse November 2026 lock-in without having a better understanding of alternatives like Tailstorm, weak blocks, Sunlight, etc. That’s more on me than on the CHIP author, but still points to the social and cognitive costs that come with such an impactful upgrade. I cannot in good faith offer a strong endorsement without thoroughly understanding it from every angle.
I think that changing blocktime naively could have unwanted second order effects on the economics of the network. One example: we’re simply assuming that exchanges will either 10x their confirmations to compensate, or be ignorant and change nothing. Without actually talking to some exchanges, we have no clue what they’re going to do, and I think that should partially inform what tradeoffs we ultimately find acceptable in pursuing this proposal.
Now, I will openly admit that I don’t know what I don’t know - and that’s a huge contributing factor to my concern that “the problem space has not been fully explored.”
In terms of the community at large digesting the proposal - frankly, I think there are many people with opinions who still haven’t even read the CHIP. It could be the best written CHIP ever, but if the community has not had time to actually read it and properly understand all of its implications, we can’t really say that we’re making an informed decision in aggregate. Right now I see enough contention (or at least lack of knowledge) on the CHIP that I think it would be rather hasty to lock in a mere 90 days from now.
This is more than just a technical issue, it’s also a social issue. I am definitely not saying that we should never adjust the blocktime or that we should stop pursuing innovation on BCH. I do think that it would be wise to target the 2028 upgrade cycle in order to ensure that we are not missing any footguns and to allow the community to demonstrate a stronger consensus.
On that note, I do think that consensus is slowly building - I don’t think that waiting will cause a roadblock. We are after all evaluating the CHIP on its technical merits, not on emotions. I don’t really anticipate a BIP-119 type scenario where we stall out on good ideas for years on end. In fact, I’d actively campaign against that outcome.
I think there’s also a strong point to be made that despite many “small wins” that combine to demonstrate benefit from the Faster Blocks CHIP, those small wins still may not outweigh the overall social and technical costs at this time. We’re talking about an effective architectural refactor for the entire ecosystem. The “YAGNI” mantra comes to mind with the whole tick system. There is in fact a lower bound to how fast we can confirm a transaction. If we use Solana as an example, they claim transaction finality with times measured in milliseconds, which indicates to me that the time is almost entirely taken by network propagation. So in effect, their security is similar to ours with 0-conf.
And of course, we can’t gloss over the fact that faster blocks are in fact addressing a symptom, and not a root issue. The issue that I think has unanimous agreement is that waiting for the 1-conf failure mode sucks in instances where 0-conf is not accepted. Discussion around the CHIP has steered away from the idea of trying to educate the ecosystem about 0-conf. I understand the sentiment, given that we can’t even get Coinbase or Binance to use Cashaddr. But we also should think about all of the other misinformation and propaganda we’ve dispelled over the years. What would make this different?
Overall, I am suggesting a cautious pause - I do not think it is necessary to rush for 2027 lock-in, and I think we would all benefit from having more time for everyone to actually grok the proposal. If “detractors throwing a wrench” is a concern, we should address those wrenches on their merit the same way we do the proposal itself. We can all recognize hand-waving bullshit and call that out - and we routinely do.
Main concern has always been those pesky headers.
On the SPV front, here’s what’s already been done, in case you hadn’t seen these:
- a whole CHIP speccing out header checkpoints (compatible with those currently used by Electrum) so wallets may prune headers: CHIP-2026-02: Simplified Header Verification for Bitcoin Cash
- a full BCHN PoC implementation extending the P2P protocol with header checkpoints: Simplified Header Verification (SHV) (!2045) · Merge requests · Bitcoin Cash Node / Bitcoin Cash Node · GitLab
- automated and trustless checkpoint extension and header pruning for Electron Cash: https://github.com/A60AB5450353F40E/Electron-Cash/commit/e383fe37be9c69af222f1b92a0cf2f3d79ad14eb
- a set of libraries to help other wallet developers implement the same: ac-0353f40e / mmr-accumulator · GitLab
What more do you expect me to do?
As for the other “issue” being thrown as an obstacle, that is specific to BIP-37 and is solvable by batching, if one wants to solve it. But to me it looks like they prefer to maintain that obstacle.
After all the CHIP’s been through, really?
Zcash didn’t seem to have any trouble there, why should we?
Not everyone is expected to read it in full. CHIP is like a dossier of the process and a point of reference. Some people may be convinced by 2nd-hand information or discussions on other channels, and that’s fine, they don’t ever need to read the CHIP body.
This kills motivation, you know, I feel we’re near the finish line and you’d have me suffer the CHIP-bearer burden for 1 more year. For what exactly? 90 days should be enough to complete the implementation and torture some testnet/scalenet network confirm it all behaves as expected, and finally in November do the victory dance of collecting statements.
Ah, the “unknown unknowns” problem. Every upgrade carries those, if we waited until all future unknowns were known, we’d never activate anything. That’s what testnet and scalenet are for: to surface the concrete, measurable issues before mainnet. But look at the broader picture: faster block times have been discussed on and off since 2014, and in all those years no new fundamental obstacle has surfaced. Dogecoin has been running 1-minute blocks the entire time (since 2014) without breaking SPV or exchanges or anything else. Zcash moved to 75s blocks in 2019 without catastrophe, and is now proposing a further cut to 25s. We’re not charting unknown territory; we’re following a well-trodden path where the unknown-unknowns have already had over a decade to show up and haven’t.
Ticks are kinda orthogonal to actual consensus change of block frequency. API will expose it, you don’t have to use it. Zcash just stuck with block height and their ecosystem managed. Under the hood, in BCHN, it’s a refactor. One could implement it all without using ticks and be in consensus, but then they’d have to do double work later, in case we ever wanted to change block time again.
I expect many wallets to not care about ticks. If they don’t do SPV why would they care? Take Cashonize, why would it need to change anything for faster blocks? It can just continue to use height.
For an entity like Thorswap, ticks should be very useful because they can fit right into their formula for required number of confirmations: delay = delayCalc(outboundValue - (cloutScore - cloutUsed))
We needed faster blocks since 2014, we’re 12 years late, here’s Gavin Andresen arguing for it in 2014:
Copy/pasted from #bitcoin IRC:
Jeepers creepers, I can’t have a half-baked opinion on ANYTHING anymore, can I?
I do think 1-minute blocks would pass a cost/benefit analysis; benefits would be less variance in confirmations-for-whatever-level-of-security (e.g. wait 60 1-minute confirmations has much lower variance than wait 6 10-minute confirmations).
I think it would probably encourage mining decentralization. Easier to solo mine if you’re competing for 1.25 BTC 1-minute block instead of a 12.5 BTC 10-minute block.
… that might not be true, would have to run the numbers for disadvantage due to higher orphan rates…
I have no opinion on whether or not the adjust-difficulty-every-2-weeks should be changed if the block time was changed, but that’s something else to think about.
Disadvantage is that SPV nodes would have to download more headers, but that’s not a huge disadvantage and I think the benefits of an SPV node finding out about a re-org / double-spend quicker probably outweigh them.
One minute is not fast enough for real-time payments, so that’s neither an advantage or disadvantage.
Whether or not to change the 10-minute block time is a separate issue (with its own pros and cons) from whether or not the max block size should change. Status-quo with a faster block time would be 100K max blocks, each with one-tenth the current mining reward.
Yes, bounded by speed of light and planet size. On Earth, I think a lower bound is some 6-10s. We don’t have to be instant, we just need to be fast enough for fallback 1-conf UX not to suck, maybe we’ll settle at something between 10s and 60s later on, and for instant UX we will depend on 0-conf like we do now, and maybe improve it with ZCEs or something.
It’s not a matter of education. Once educated, you will understand that it’s risky to accept 0-conf with DSP score 0, and you will ask for 1-conf (e.g. Bitgree - “What happens if a double-spend attempt is detected?”). I think some proponents of 0-conf, who think of it as the panacea, are really the uneducated, because they think it can just work in all contexts and without risks/trade-offs.
There are contexts for which 0-conf is not good, and 1-conf or N-conf will always be required, and faster blocks will help smooth out those experiences. Education won’t make these contexts go away, they will always be there, and be a nuisance as long as we have 10-minute block time.
5 Likes