2027 protocol upgrade ideas

#18

Is this not fixed yet? Or are you trolling and we have already fixed it? If not, what’s required to be changed? I know it’s a meme joke in BTC like “we do need to do this, if we can’t get consensus for even that we’re screwed but haha it’s so far away”. But yeah if we can fix it now we should.

Well it was “non breaking”, but we’ve still seen around 2.5 years of work even after the May 15 go live and CashTokens addresses are still not well integrated into everything directly within BCH, certainly not fringe BCH (like Bitcoin .com wallet) and basically not in the slightest to exchanges or anyone further out. So in practice, changes similar to CashTokens are a pretty big deal even if they’re technically “non-breaking”.

I’m a big fan of 1 minute blocks, and I feel like everyone is trending towards it nicely at this point. You see users basically every week wondering about why confirmations are so slow, which is natural because BCH is drawing in interest and adopters (especially with the community hyping up our BCH DeFi) from all other coins where the competition just has far superior confirmation times. It’s an immediate stumbling block they hit and dislike, and really takes the shine off the rose in terms of being excited about all the great stuff in BCH.

I think a no-op year would actually be quite healthy from a governance point of view, there’s no shortage of things to be built out in BCH and it’s nice for the community to feel changes are not being rushed or forced. BUT the benefit of that is fairly small compared to the opportunity cost of missing an entire year cycle of upgrades (essentially nothing new sans Layla go-live until May 2028, an eternity away). As Luke says, we do in general want to ship as much in as fast as we can, because the bigger we get the smaller the ability to coordinate important upgrades will likely become.

Agreed. Many such opinions in the community. People who don’t have the pain point feel status quo is “good enough”, but people with the pain point of blocktime REALLY feel it hard. And 1 minute blocks doesn’t make the situation for 10 minute block preferrers any worse.

28 is a different discussion. 1 year from now, by the start of 2027, the crypto landscape will have shifted again dramatically. So that’ll be.a fresh conversation to be had then. New proposals, significant community growth, new research and trending tech (maybe something specific around say quantum or ZK or AI could be huge) etc. So yeah too early to tell on that one.

Aside from all that, one thing I want to throw in the mix which is a real /someone problem, is the stuff around unifying relay policy and consensus. At the very least we need a proper writeup of what exactly are all the little things left around that, and some analysis of what can or should be unified and what left as it is or solved another way (e.g. the dust threshold?? Minimum fee relay floor??). I have a thread here which is the best I’ve done so far at tackling this issue.

But that would be an awesome one for the wishlist - at least some proper research, which may or may not turn into an actual CHIP.

4 Likes
#19

This has nothing to do with addresses.

Work on what? The output format extension worked fine since day 1. Block explorers can work fine non-upgraded, they’ll just show some weird-looking scripts instead of decoded token+script. See this example: Trezor Bitcoin Cash Explorer

The “Unparsed address” entries are token outputs, but explorer decodes the whole token+script payload as if it is some unknown script. But the non-upgraded explorer works, it did not crash, it can parse transactions just fine, even if there’s this 1 piece it can not understand.

If we’d add more output fields the same way we added tokens then we’d just turn some more outputs into “Unparsed address”.
If we’d break TX format for v5, then such change may crash non-upgraded software like the example explorer.

So yeah, it takes time for everyone to properly support new features like CashTokens - BUT, when it is non-breaking - the old features will continue to just work, without downstream software breaking, and then it can upgrade at its own pace.

1 Like
#20

So as soon as we get more usage this problem will basically solve itself.

DEX’s such as Thorchain rely on confirmations, nothing moves until a confirmation is there.

They will never let you swap 100 BCH and pay you out before there is a confirmation. Not going to happen.

We need faster blocks if we are to compete, others already have near instant confirmations.

4 Likes
#21

It’s not just DEXs. Not all 0-conf transactions have the same risk, see CHIP 2025-11: Unsettled Inputs Break Zero-confirmation Transactions - #4 by bitcoincashautist.

Example 1: if you swap some token for BCH on Cauldron DEX, and immediately use that unconfirmed UTXO to pay a merchant, such 0-conf has increased risk of getting cancelled because it has an unconfirmed “anyonecanspend” ancestor.

Example 2: if you put dust in an OP_1 “anyonecanspend” P2SH UTXO and reference it as input in your TX, then any miner monitoring for such “free” UTXOs could sweep it and effectively cancel your TX, so a payment that has any input spend P2SH also has increased risk of getting cancelled.

5 Likes
#22

Thanks for the info.

I also noticed that even Cauldron gets hung up sometimes when there is too many unconfirmed swaps on a token and will not work until a conf comes in.

10 minutes was fine 10 years ago but now is just too long.

4 Likes
#23

You selling 100 BCH isn’t going to get processed with 1 confirmation either :wink: It would need a bunch of blocks. So your base assumption is false, “a confirmation” is not what is targeted, instead a certain amount of (proof of) work is.

Faster blocks doesn’t actually give people what they hope it gives them, this is a good example where hope outstrips knowledge. If you talk to many people in the community you’ll notice the pattern, they expect a lot of issues to be solved with 1 min blocks that upon critical review, there is no reason to believe they will be solved with 1 minute blocks.

These examples really just show the problem of finding actually beneficial outcomes that are not trivial to debunk, BCA here creates completely imaginary situations that not a single wallet today is capable of producing and claims it is a problem that needs a solution. While in actual fact not a single human ever had this problem, and as such doesn’t need solving. They can’t have had this problem since no software exists that does this, or anything close to it.

And on top of that, the solutions to this imaginary problem are easy and obvious to any engineer, they automatically follow from basic UX requirements and they do not require you to have faster blocks.

The basic premise of the faster blocks change is that people hope it will make the price go up. As CashDragon here says “we need this to compete” and Jeremy said basically the same thing in another thread here on BCHR. Talk on Twitter and Telegram as much as you want in order to influence the price, but this forum is the wrong place for that.

1 Like
#24
  1. app.cauldron.quest → create wallet
  2. buy some tokens
  3. create a liquidity pool with those tokens
  4. destroy the liquidity pool before block confirmation
  5. send the bch back to your regular spending wallet
4 Likes
#25

No matter how you look at it faster blocks will speed things up just due to lower variance, if blocks always came in 10 minutes apart there would be no issue, one minute blocks effectively gives us 10 minute blocks in the worst case scenario.

5 Likes
#26

Kallisti, you provide some steps, not sure which wallet actually does any of that. It probably is some web page, not a wallet. Nothing you can use in a store at the payment terminal. “Oh, wait a moment sir, I need to scan your QR to find the address to then go through this website and do some shit there to pay you from my withdrawal.”

So in reality you went to a website to send money to your wallet address. But that is not the scenario BCA was talking about.
He was talking about the transaction needing to be protected FOR THE RECEIVER. Which you yourself are here. There is no danger, no problem to solve in the scenario you gave.

So maybe you forgot the add the last line:

  • go to a physical store and spend your coin from your mobile wallet.

Well, and for that go actually happen, that wallet you have on your phone should prefer unconfirmed UTXOs, which AFAIK none of them do… And you have to be pretty fast to avoid your website initiated transfer having confirmed before you get to the store and select your goods or drinks and finish them to get to the point where you pay.

The end result is that there is nobody that is seeing problems today, because the scenario is just not something that happens in real life. No actual (single) wallet can create this issue, and existing ones combined don’t run into it either.
On top of that, the solution is trivial, the end user that creates this issue ends up waiting for a confirmation at the payment terminal. Because DSProof is about enabling the 99.9% of usecases, not about making that 100%. You can avoid becoming the 0.1% and keep things going smooth.

And to strengthen the point; making a change to the protocol as massive as block time changes needs actual real life problems to be solved. Not some imaginary problems that we are not seeing any amount of actual end users having problems with.

Lets not do what Peter Todd did to push through RBF; be the attacker and victim in an artificial scenario that when it “succeeds” in failing is then used as proof to show it is a real issue.

#27

ok, I see what you’re saying. tl;dr we addressed this in this thread: CHIP 2025-11: Unsettled Inputs Break Zero-confirmation Transactions - #17 by ShadowOfHarbringer

This definitely can become a bigger issue as the ecosystem evolves though. More user wallets will be able to make more complex transactions in the future… let’s say I’m at a merchant POS and I have a special savings vault contract that I need to access, because I forgot to do that transfer in the morning before I got to the store… no problem, I’ll spend from the contract into my everyday spending wallet… but the transaction is unconfirmed, and now the inputs have a non-p2pkh ancestor…

perhaps I misunderstand somewhere - the non-p2pkh ancestor is assumed to be confirmed in the example, I suppose, so maybe that’s also a non-issue.

AFAIK we currently don’t have any wallets that use contracts directly as inputs… unless maybe paytaca does this with their stablehedge feature.

regardless…

the solution is trivial, the end user that creates this issue ends up waiting for a confirmation at the payment terminal

yeah… shouldn’t be much longer than 10 minutes from now, eh? :innocent:

5 Likes
#28

The point you’re side-stepping is that the solution lies on the side of the end-user. The tech doesn’t have to be fool-proof. The universe will always invent better fools in response anyway.
The current status is that the 99.9% of the usages on chain are in actual fact protected and will not be miner extractable value and thus there is no reason whatsoever to doubt they will get mined the next block.

Sure, smart people can come up with scenarios THAT NOBODY IS SEEING TODAY which fall in the 0.1% which may be exploited by a miner, a thing that hasn’t actually happened in the lifetime of Bitcoin either.

But the solution to that is to detect them early on and put the responsibility squarely on the wallet makers and users because this really never happens to normally honest behaving users using well designed wallets. So, if a point of sale hits this, the user simply get checked more. Because of the inherent issue of this being possibly a scam. The risk of the merchant getting scammed. :man_shrugging: It really isn’t complicated and the industry is entirely used to this kind of solution.

In short: avoid behaving like a scammer and you don’t have to wait for the (maybe more than) 10 minutes. Everyone happy. No protocol changes needed. Like Shadow concluded in your linked thread, the lower level parts are all solved.

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

2 Likes