SPV works differently than you say, the security is different.
It is written more here:
SPV wallets are actually the main ones that will stop being usable with one minute blocks. Add one minute blocks and SPV will die. I develop such a wallet, have been here for about 15 years. One minute blocks will kill BCH for peer to peer, decentralized payments.
Can you please explain how 1-minute blocks kill SPV?
And why didnât they kill BIP-37 SPV on Doge?
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.
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.
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 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!
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.
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.
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.
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
bwahahaha 
good luck with that 
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.
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:
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 
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.
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.
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.