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.
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.
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.
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:
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!
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.
