I like the idea of global function tables, not so sure we need read-only inputs for that. Here’s something to ponder: CHIP-2025-01 TXv5: Transaction Version 5 - #19 by bitcoincashautist
2 Likes
Contract Limits
Some of the ideas in the TXv5 CHIP can easily be separated out and done in 2027 without breaking the transaction format and needing to be an ‘omnimbus’ CHIP which bundles many unrelated items.
Particularly the idea around further relaxing the contract limits after the VM Limits CHIP:
Maximum Bytecode Length
The existing 10,000-byte limit on maximum bytecode length (A.K.A.
MAX_SCRIPT_SIZE) is raised to 100,000 bytes, equal to the limit on maximum standard transaction byte length (A.K.A.MAX_STANDARD_TX_SIZE). See Rationale: Unification of Byte Length Limits.Maximum Stack Element Length
The existing 10,000-byte stack element length limit (A.K.A.
MAX_SCRIPT_ELEMENT_SIZE) is raised to 100,000 bytes, equal to the limit on maximum standard transaction byte length (A.K.A.MAX_STANDARD_TX_SIZE). See Rationale: Unification of Byte Length Limits.
with rationale
Unification of Byte Length Limits
Following the VM Limits CHIP, bytecode and stack item length limits are no longer relevant to worst-case transaction or block validation performance. As standard transactions can include many inputs – up to the maximum standard transaction byte length (A.K.A.
MAX_STANDARD_TX_SIZE; 100,000 bytes) – lower per-item or per-input length limits offer no additional safety to the network while inconveniencing applications with larger contiguous data requirements.For example, many zero-knowledge and post-quantum cryptographic systems require proofs larger than 10,000 bytes; with a lower per-input and/or per-item limit, these proofs must be broken into multiple stack items and/or inputs, requiring the development of unusual standards, significant waste in data manipulation bytecode, and unnecessary contract complexity.
In practice this unification saves ~40-75 bytes per 10,000 bytes by eliminating the need for bytecode and data to be divided among push operations and adjacent inputs.
Base opcost
The Loops CHIP at some point suggested lowering the base instruction cost for opcodes
Base Instruction Cost Reduction
The Base Instruction Cost is reduced from
100to10.
but this was reverted afterwards:
- v1.2.3 – 2025-09-05 (
bd3ebc76– diff vs.master)- Revert “Reduce Base Instruction Cost” (#8)
- Update VMB tests and benchmarks
- v1.2.2 – 2025-06-30 (
9c1f55d9)- Reduce Base Instruction Cost
I think this could be a good idea to bring back into the discussion.
My thinking on these limits is informed by experimenting and building BCH native Groth16 contracts and the related Verifier.cash competition, see Optimized Groth16 verifier contract for BCH (Verifier.cash initiative)
8 Likes
1-minute blocks ASAP 
3 Likes
Welcome to BCH research!
Completely agree with you. 
Perhaps you could elaborate on why you’re so keen about 1 minute blocks to help others who might be more doubtful see how you came to that decision?
SPV wallet users. SPV wallets don’t check transactions themselves, they only check if a transaction has been included in a block. Without a confirmation, the SPV wallet has to trust the nodes it interfaces with. 1-minute blocks makes the confirmation come quicker.
4 Likes
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?
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