2027 protocol upgrade ideas

#29

even without those scenarios, faster block time are a general improvement that will make life better for everyone facing any confirmation requirements for whatever reason
image

4 Likes
#30

I don’t have anything against organic “no-op” year, as in – nobody put in the effort to have something ready, for whatever reason. By accepting “no-ops” can just organically happen we don’t fall into the trap of “oh but we have to have something to show this year, so let’s rush something”. If nothing is ready, it’s fine if we get a “no-op” year.

But to have intentional “no-op” year would be silly, as in – even if somebody had something ready, we’d just let it sit out a whole year before activating it.

Elliptic curve cryptography may become obsolete in a decade or two. I don’t think we should add these opcodes knowing that they have limited shelf life. For cases like this I think read-only inputs are the better approach - you could once define your own EC op using Script, and then call it from other contracts as many times as you need with only 40-50 bytes of overhead for “loading” the function into your contract, and then you just do OP_INVOKE in places you need it.

5 Likes
#31

Makes sense. Maybe the same effort would be better spent toward making some kind of on-chain “standard lib” for stuff like this :slight_smile:

1 Like
#32

Before they grow too much in your mind, the concept sets off all sorts of alarm bells with regards to scaling.
I mean, people explain op-return as not filling the utxo, but then want a special output that can never be reaped? That just sounds like a really easy attack vector.

So before this idea grows too much in your mind, please do (or wait for someone else to do) the scalability research on how this affects utxo growth and thus the cost of a node operator.

1 Like
#33

CHIPs describes the balance a bit better than this.
There are a lot of what are called “stakeholders”.
The point is that it is not just “somebody” that made a thing. While we value those people, they are really a small minority in the list of stakeholders. As such I feel the need to push back to your statement that it is silly to make them wait. In reality there are a lot of stakeholders in the forms of people and companies that need to actively agree to the disruption that results from protocol upgrades.

You do remember the head of bitcoin com stating that it is actually very expensive to support bitcoin cash because of the continues upgrades?

The stakeholders that find yearly upgrades too expensive will not come here and object, they’ll just leave and maybe go to build on another chain.

1 Like
#34

Bumping this with some fresh thoughts. Soon, on May 15th 2026, we’ll be getting:

What’s next? I’m already working on CHIP-2025-03 Faster Blocks for Bitcoin Cash, and I’m starting to think it can’t make it for 2027, and will probably roll over. Too much work still needed, and testing will be a bigger job than with previous upgrades.

Recently Google’s Quantum AI team published “Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations”, which made some waves. It is comprehensive, I suggest people at least skim through it or have an LLM summarize it. This has prompted me to pick up on some work I shelved in 2023 and produce “Quantum-Resistant Bitcoin Cash: A Challenge-Based Transition Protocol” and a draft plan for BCH’s transition.

Transition to what? We are in a good position with @bitjson’s Quantumroot, which will become practical with upcoming May 15th 2026 upgrade. I expect first wallets to become available end of 2026 or in 2027. Currently, QCs can’t do anything, threat is still hypothetical. Still, the fear of QCs is real and can strain people psychologically. Having a plan for q-day will help that.

With that in mind, I now have 2 wishes for 2027:

  1. Native introspection of mature block headers
  2. OP_SIGHASH (aka OP_CHECKTEMPLATEVERIFY in BTC circles)

Both will potentially enable smoother transition to post-quantum. The OP_SIGHASH allows us to maintain current standards for signature preimage constructions, even when people start to implement their own signing schemes using Script. The header introspection lets contracts efficiently prove a commitment UTXO’s age, which matters for commit-delay-reveal implementations.

PS Interestingly, faster blocks would somewhat help against QCs, too, because Google estimates it will take 9 minutes to crack a key. With 1-minute blocks, people could have their TX mined before an attacker could crack their key and continue to use P2PKH, but with reduced security properties (miners could collude with QC attackers to delay a TX long enough for key to be cracked). Google’s paper acknowledges this:

For example, we estimate the success probability of an on-spend attack using a superconducting qubit CRQC against Litecoin, a Bitcoin derivative which targets 2.5 minutes between blocks, to be less than 3%. The chance of a successful on-spend attack on Zcash, whose target block time is 75 seconds, is less than one in thirteen hundred and on Dogecoin, whose target block time is 1 minute, is less than one in eight thousand

5 Likes
#35

I would also really like to get this for 2027. I should have time to write a formal CHIP in May and will draft an MR for BCHN in a month or two.

Not necessarily expecting it for 2027 (still some details to flesh out and consider), but I think I’m becoming a big advocate for Jason’s “read-only” inputs too: These allow for Contract System Architectures where UTXOs can behave as fixed functions that we can pass arguments (other stateful UTXOs) in/out of which’ll probably simplify and make many contract systems cheaper.

5 Likes
#36

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
#37

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 100 to 10.

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
#38

1-minute blocks ASAP :smiley:

3 Likes
#39

Welcome to BCH research!

Completely agree with you. :grinning:

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?

#40

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

4 Likes
#41

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.

#42

Can you please explain how 1-minute blocks kill SPV?

3 Likes
#43

And why didn’t they kill BIP-37 SPV on Doge?

4 Likes
#44

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.

#45

Ask the full node for a range of blocks, not one-by-one.

3 Likes
#46

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
#47

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 :point_down:

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 :unamused:

cheers!
:beers:

5 Likes
CHIP-2025-03 Faster Blocks for Bitcoin Cash
#48

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 :roll_eyes:

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