2027 protocol upgrade ideas

#1

To continue a bit of a tradition (2021-2023, 2026), this thread is to discuss our collective 2027 upgrade wishlist.

Jeremy, Ryan, Fiendish, and I briefly discussed our opinions on the current CHIP landscape on the 2026 end of year BCH Podcast episode. At the time of writing, it seems that CHIP-2025-03 Faster Blocks for Bitcoin Cash is a potential candidate for the 2027 upgrade cycle, but the CHIP is not complete nor does it have clearly unanimous consensus.

I don’t believe any other CHIP is “on-track” at this time, but that could change. There’s also the potential for 2027 to be a “no-op” year, which may be of some benefit purely to demonstrate discipline in our upgrade process.

Some other notable CHIPs to review and discuss:

All of these CHIPs are currently incomplete and lacking consensus, but may be of interest for further research and development.

An interesting observation: searching this forum for “CHIP” shows how far we’ve come… I would almost believe that if BCH were to ossify today, we’d still be in a great position. The search also shows that we peaked in development activity between 2023 and 2025 - there are only a few new or outstanding CHIPs that have been formally proposed and NOT merged or withdrawn at this point.

On a personal note, I’d like to poke at the idea of “OP_PFX” for purchasing more VM compute budget without inflating script sizes… and I have an inkling that it may be acceptable to raise the OP_RETURN limit to fill up to the maximum transaction size of 100,000 bytes (where OP_RETURN would NOT purchase additional VM compute). Just want to bring these topics up for discussion :slight_smile:

Total aside: when should we fix the 2106 problem? :grin:

* Edit: It is generally agreed that UTXO commitments do not require consensus/protocol-level coordination, but is listed as an honorable mention.

5 Likes
#2

Today I’ve been looking into TXv5 in more depth in order to better understand its current status.

The TXv5 CHIP currently aims for mainnet deployment in May 2027. But the CHIP author asserts that if the cost of introducing a new transaction format is too high in 2027, there is still value to be gained by considering some of its components:

CHIP-2025-01 TXv5: Transaction Version 5 - #6 by bitjson

…two components could reasonably be extracted from TXv5 (if BCH doesn’t have sufficient market dominance by 2026 to lock-in a transaction format upgrade), making this into 3 CHIPs:

  1. Read-only inputs – the implementation in the CHIP is already backwards compatible, the TXv5 part just adds a more efficient encoding
  2. Unified bytecode length limits
  3. The v5 encoding itself (everything else in this CHIP)

If an improved encoding format still looks too disruptive in early 2026, I’ll just propose the smaller, backwards-compatible items (1 and 2) for 2027, and re-propose the v5 encoding for 2028.

#3

For anyone interested in this, it’s elaborated here: CHIP 2021-05 Targeted Virtual Machine Limits - #137 by bitcoincashautist

Since you highlighted this aspect, it prompted a few thoughts. It already doesn’t purchase VM compute budget (but in the past VM limits CHIP iteration, a shared TX budget, it would’ve). But why shouldn’t it be able to “purchase” budget? The objective of VM limits is to control CPU density per byte to avoid hot spots, and all outputs are “dumb” bytes and reduce CPU density of the TX because they don’t contribute to budget so they dilute TX’s CPU load. But maybe we could include them: sum all output bytes and divide by number of inputs then add that to each input’s budget. Or, any PREFIX_EXTRA_BUDGET invoked would first “claim” bytes from these currently unclaimed places in the TX, before claiming imaginary bytes (which would count against TX size and block size limits, just not be encoded anywhere and use bandwidth for nothing).

But I’m not sure if all this will really be needed, because a bunch of 0s from a data push are highly compressible and could be transmitted over network in compressed form.

#4

This may be very positive for the growing of the community. Having new stuff every year makes people already there excited, but it doesn’t do much for attracting new blood. Stability and a good base will have a lot of positive influence to allow builders to build and not lose the footing.

#5

Because keeping the chain small is still a serious objective. More transactions fit in the same blocksize as a result.

Today the miners have no way to set the cost to mine a transaction. The producers of blocks can’t set the price of stuff they put in it. There are no tools to do that. There could be, without consensus changes, but miners can’t say that the 100KB mostly op-return transaction should pay more per byte than a transaction that merges 1000s of UTXOs into one of the same size. While the value for the miner and the network is clearly different.

Should we get full blocks, the pressure to get such tools is going to grow. Miners want to optimize cost and value-creation as much as users do. And most users will definitely prefer 400 boring transactions getting mined over 1 op-return one in the same limited blockspace.

So, thinking ahead, op_pfx would allow someone to purchase extra compute without it pushing out a lot of transactions from the limited block space. Which makes everyone happy, the miner gets paid for the op-pfx usage AND the transactions actually doing payments get mined (which the miner gets payment for too).

Or, in simpler words; Create incentives that are misaligned with the goal of Bitcoin being Cash, you disrupt the system. It’s like Gavin Newsom started paying non profits for homeless people, which objectively grew the number of homeless people.

Align your incentives. That could be the simplest explanation of op_pfx :slight_smile:

#6

Note that the imaginary budget bytes added by op_pfx would count against limits as if they were actually part of the TX. Say you have a 1kB TX which “buys” 9kB extra budget by using the pfx. You could only pack 3,200 of such TXs into a block and NOT 32,000 of them, so your block would end up being 3.2MB and at the limit - because those “imaginary” bytes would count - the block would be using as much CPU as if it was a 32MB block filled with reference P2PKH TXs. Of course, the miner could choose to evict one of those 1kB TXs from his block template and replace them with 10kB worth of regular TXs. You can think of it as a compressed TX, but it’s evaluated decompressed against the block size limit.

The pfx would clearly mark the imaginary bytes as such, so I guess this ties in well with your idea of helping miners price these differently from regular TXs, intent behind the bytes would be clear. With op_return or input script - you can’t easily tell whether some bytes have some other purpose than “buying” the budget so makes it harder to have special pricing policy for extra budget bytes.

2 Likes
#7

Good observation! That is the kind of thing that needs to be researched. Finger in the air thinking, I’d expect that since the VAST majority of transactions never get close to the limits, your miner will indeed be able to allocate more transactions in the same blockspace when the couple that actually want more budget (RARE!) use op-pfx.
But research is good, to run the numbers and see how that works out would be great.

How cost is defined is up to the actual producers. The miners. It’s basic economics and free market. Better to interfere as little as possible in consensus rules. All we have to do is not fuck it up by creating misalignments.

#8

Since OP_RETURN is unspendable, we never need to spend compute on evaluating unlock conditions later when used as an input.

OP_PFX to explicitly request extra budget without needing the real bytes seems cleaner?

1 Like
#9

Still being fleshed out, but I wouldn’t mind putting this on the table for consideration in 2027:

Technically, the implementation shouldn’t be high-effort (it’s just exposing a subset of OP_CHECKSIG under a new op-code). But it’s contentious whether we want to consume an OP_CODE when we might have a more generalized malleability fix under Jason’s TxV5 CHIP.

3 Likes
#10

I’m not convinced we need a new TX format since we can just add new fields in a non-breaking way (like we did for CashTokens) to existing TX format, see this technical bulletin “Evaluate Viability of Transaction Format or ID Change”

OP_SIGHASH would be useful regardless of detached signatures, as it’s just a compact way to have contract commit to TX contents using already standard templates, regardless of whether the commitment will be signed or not.

3 Likes
#11

I would love to see more discussions on these below for 2026

1- CHIP-2025-03 Faster Blocks for Bitcoin Cash
2- CHIP-2021-07 UTXO Fastsync
3- block-download-merkle-root-addition-torrent-like

More topics on UTXO commitment and stateless validation on BCH

2 Likes
#12

op-env would avoid that, just reuse op-code with an extra byte or whatever.

#13

2 and 3 are not consensus, though. They can be done perfectly fine decentralized. Permissionless. Which means you don’t find people to talk about doing it, but find someone to actually code it.

2 Likes
#14

Personally I don’t see the benefit of this “no-op” year. The vast majority of market participants don’t pay attention to such things anyway. Time is not on our side, as more people come in and the market cap increases the risk of ossification increases. This is especially true with no centralized governance structure.

I would still love to see 1 minute blocks be the focus personally. Zk snark technology is also becoming more relevant and it does seem to me we will need at least 1 or 2 dedicated op codes such as the ones in CHIP 2025-05 Native Elliptic Curve Arithmetic Operations.

The zk opcodes are kind of nice because they are more straight forward for implementing, although more research is needed.

Txv5 seems too early still, but I wouldn’t mind that getting in either.

2 Likes
#15

Would be amazing to get these 3 ready for 2027. Fast blocks is a must, I do a lot of DEX and merchant payments and BCH is painful when we have no block for 40 minutes.

2 Likes
#16

In the last months and the revival of our price we’ve already been seeing a lot of positive attitude towards bitcoin cash. Some exchanges changed behavior (proof of reserves, less confirmations) and we’ve seen some services starting to use our features where they simply just were generic bitcoin-ish before.

As our price keeps on rebounding and adoption is expected to grow, the most perfect solution will become available without a protocol upgrade: the acceptance of merchants and similar of zero conf (instant transactions). Because they are basically low enough risk that this is fine and safe.

So as soon as we get more usage this problem will basically solve itself.
Can’t wait to see how much more adotion and support the coin will see in the next years!

#17

1 min blocks for 27
nothing for 28

2 Likes
#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.

1 Like
#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.

1 Like