2026 protocol upgrade ideas

[tom]

We had this old old topic years ago where people wrote what it was that they wanted to happen or work on. Let’s re-do this and get people excited about doing the hard work for the next year to make some more cool stuff happen. I’d gladly assist and maybe we can have some 𝕏 spaces to brainstorm about this. Because most of us are not going to be spending months putting everything on hold to get a CHIP through… Maybe we can pick some we all want and actually cooperate from early day.

I have a long list of stuff that I’d love to see some day, but those largely don’t require any coordination event. As such I won’t mention them here.

My personal list, in no particular order:

• Milli-sats.
  Needs some ‘breaking’ transaction-format idea to avoid mayhem.
• OP_ENV which is like a versioning of the VM behavior. Needed to do millisats integration.
• OP_EVAL fetch data from anywhere on the Tx and execute that in my VM limits.
  Probably quite trivial.
• OP_PFX. Pay more to get more rights (cpu time) without polluting the blockchain.
  Should be very trivial to do. Only touching the full nodes.
• OP_LOOP. Because Turing completeness is hot.
• P2P-network messages “send-tx” and “tx-ack”.
  Today peers use a normal ‘tx’ message to send the transaction. And they may get a ‘rejected’ returned. But they never get a response if it went Ok.
  This idea of the new messages are for transaction producers to solicit either a ‘tx-ack’ or a ‘rejected’ response. An ‘tx-ack’ would also contain extra information indicating if the transaction was already in the mempool and how long the node will keep the transaction in mempool if it doesn’t get mined (too low fees, for instance).
• relax output standardness rules.

Any I missed? Anything others want?

[ShadowOfHarbringer]

• Nested Proof Of Work / Infrastructure Blocks

[BitcoinCashPodcast]

• UTXO Commitments
• Sub sats
• Bounded Loops (I’m still a bit unclear on this one, but @bitjson is excited so I’m excited).

[tom]

The two last ones are duplicates from my list. (milli-sats and op-loop respectively). Yay, we agree

Commitments can be deployed without a protocol upgrade to get something useful, and if it works that makes it 100x easier to propose a change in the blocks to add that somehow.
All in all, this one is a very large undertaking that probably will take years to do.

[gotamd]

Hopefully the upgrades to scripting capabilities drive adoption to the point where UTXO Commitments become “necessary.” It’s something I’d love to see. To me, UTXO Commitments are one of the last remaining foundational components to make the system indefinitely sustainable.

[jimtendo]

Lots I’d love to see, but Bounded Loops are the big one that comes to mind.

Also, though I’m not itching for it, will add this as another item:

Relaxing output standardness

Following CHIP: Targeted Virtual Machine Limits, output standardness is no longer useful for limiting the worst-case performance of transaction and block validation. (See Rationale: Use of Input Length-Based Densities and Rationale: Selection of Hashing Limit for some specific mentions of relaxing output standardness.) I plan to propose a CHIP for 2026 to relax output standardness by allowing all outputs that are shorter than the longest currently-standard output type (bare multisig) such that …

[tom]

oh, right! Output standardness is technically only a relay / isStandard rule, but it would definitely benefit from being changed for all participants at the same time.

So that one would fit this list too!

I could still edit my initial post, so I added this one there.

[sandakersmann]

• Avalanche
• 2 minute blocktime

[ShadowOfHarbringer]

@BitcoinCashPodcast

Bounded Loops (I’m still a bit unclear on this one, but @bitjson is excited so I’m excited).

For bounded loops

Bounded loops are basically normal loops like in any programming language, however they are limited in amount of processing power/resources they can “steal” from Bitcoin nodes (without this security measure you could essentially break the network).

This means that Bitcoin’s language is getting even closer to any normal programming language. The potential for amazing things that can be built here is basically unlimited.

So yes, very HYPE

[bitcoincashautist]

@tom

OP_PFX

This came up during our discussions about VM limits, and I’d like to elaborate more on this, so added a post here:

CHIP 2021-05 Targeted Virtual Machine Limits

I’d like to elaborate more on this. It would declare some “filler” bytes, without actually encoding them and wasting everyone’s bandwidth / storage. For all practical purposes we’d treat them as if they exist, as if some imaginary <0x00..00> OP_DROP NOP sequence is actually present in the input, meaning they’d count against the min. relay fee, script size limit, TX size limit, and block size limit. It could be defined like PREFIX_EXTRA_BUDGET, something encoded outside the input script, a “pre…

[kzKallisti]

Would love in 2026:

• Millisats
• OP_PFX

Could love in 2026 if well-researched:

• OP_ENV
• OP_EVAL
• OP_LOOP

Open to being convinced, maybe in 2026:

• tx-ack
• relax output standardness rules

Open to being convinced, probably not for 2026:

• Changes to blocktime
• Nested PoW / Infra Blocks

Definitely don’t want (no thank you):

• Avalanche

Special mention:

• UTXO Commitments, although this doesn’t need to be at protocol level right now

[jimtendo]

@ShadowOfHarbringer

This means that Bitcoin’s language is getting even closer to any normal programming language. The potential for amazing things that can be built here is basically unlimited.

Can it run Doom though?

[ShadowOfHarbringer]

@jimtendo

Can it run Doom though?

For serious actually, running DOOM on things can easily make it into the biggest news outlets like even Wallstreet News Journal etc.

So if you can make it run DOOM, BCH will hit big news outlets.

[ShadowOfHarbringer]

@kzKallisti

Open to being convinced, probably not for 2026:

• Changes to blocktime
• Nested PoW / Infra Blocks

Making Nested PoW for 2026 will be very hard work for me. I will have to create a testing-network with testnet-in-a-box/dedicated testnet with multiple nodes to make sure it all works together nicely. Then run it for 6 months+ or so to prove to people and companies it is reliable.

Unless I get some external help maybe, 2026 is difficult.

But I am OK with moving it to 2027 if I cannot make it. No rush.

[tom]

About milli-sat.

A little discussion on telegram gave some good ideas and opinions. One of the main ones is that the cost is high for a currently low return on investment.
High cost is because all parties parsing raw transactions should adust their software or risk losing money.
Low return on investment is because our current price is such that there is no benefit yet.

One suggestion made was to simply avoid assumptions about schedule. Don’t assume it will fit in the november/may design we’ve been using.
Instead say we want to activate this in 4 years. Give everyone a clear indication and notification. Have a testnet soon and all that.

Or, maybe even simpler; start the process now and have as part of this specific chip the actual lock-in date and the activation date. We likely won’t be using November 2025 and May 2026 for that, but maybe November 2025 for lock in but May 2029 for activation.
All dates are draft and open for discussion.

With this much longer timeline it may be possible to not break the transaction format at all. Just change the value in a new tx-version.
Or, if people STILL find that too risky, then the longer timeline means we might fit various transaction-format-cleanups at the same time.

Having those dates part of this CHIP gives us lots of options, hopefully one will please enough people to make it happen

[bitcoincashautist]

@tom

Or, if people STILL find that too risky, then the longer timeline means we might fit various transaction-format-cleanups at the same time.

There’s also the “evalutaion of alternatives”, it needs to be demonstrated that bumping TX version and breaking TX format to shift value for x1000 has better trade-offs than inserting a new field in a non-breaking way, using the same prefix approach CashTokens used.

The non-breaking alternative, add an additional field to output format:

Field	Length	Format	Description
value	8 bytes	unsigned integer(LE)	The number of satoshis to be transferred.
subsat prefix and locking script length	variable	variable length integer	The combined size of full subsat prefix and the locking script in bytes.
[PREFIX_SUBSATS]	1 byte	constant	Magic byte defined at codepoint 0xff (255) and indicates the presence of a subsat prefix.
[subsat amount]	variable	variable length integer	Amount of subsatoshis
locking script	variable	bytes(BE)	The contents of the locking script.

Note: if the output encodes both subsatoshis and tokens, then subsatoshi prefix MUST come after the token prefix.

Applications could choose on how to present the high-precision composite:

• As a floating point: float_value = value + (double) subsat_amount / (1<<64)
• As high-precision atomic units: atomic_value = (uint128) value * (1<<64) + subsat_amount

Script VM could be upgraded using some OP_ENV so to have introspection opcodes return the high-precision atomic_value, or we could just add 2 new introspection opcodes.

[tom]

@bitcoincashautist

it needs to be demonstrated that {} has better trade-offs than {} a non-breaking way

The ‘non breaking way’ is adding tech-debt. Unneeded complexity. Complexity that can never ever be removed again because once in production those transactions stay forever.
We picked hard forks over soft forks and we relished in the fact that we can do things more clean and with much less tech-debt as a result. And this is useful to keep the chain long-term viable.
I want BitcoinCash (the protocol) to still run mostly unchanged 20 years from now. Maybe even longer, but I dare not look that much into the future.

So, sure, it is possible to do push this data into a script field and make all script parsers adjust so transaction parsers can wait a couple more years to do so.
Yes, that may short term be a positive thing.

But, people, if you think short term why are you worried about enabling mili-sats?

The trade-off of doing this inside of the value field is that it is by far the least invasive change possible. It is very simple to write the code in practicall all parsers. If txversion < 10, multiply ‘amount’ with 1000. That’s it. One line spec.

The risk of some old software messing up is a deminishing one over time. Software honestly has a horrible half-time in our crypto world. This is a super managable problem, just by giving it time.

[lucasmcducas]

First post here. First of all I am not a dev so I am not super technical. However, it is quite obvious to me that the biggest problem with BCH currently is still usage. We do not consistently even produce 1mb blocks. So in my mind things like utxo commitments are things that are still not as important as allowing more apps to be built on bch. Speed is a factor in this, but with dsproofs and ZCE’s perhaps that is all that is needed. Things like Tail Storm or shorter blocktime will not be doable this go around anyway most likely.

So in my mind it would probably be best to do another round of VM upgrades to allow even more future capabilities for builders. Everyone’s deep in the VM right now anyway so maybe this would also help while its still fresh in everyone’s minds. The ones that seem to be the most pertinent after talking to @MathieuG are:

• Loops
• re-enabling LSHIFT / RSHIFT
• perhaps adding new math opcodes for more complex market makers

Those are my thoughts at this time, thank you.

[BitcoinCashPodcast]

Welcome to Bitcoin Cash Research!

It’s true that driving adoption is a huge focus we need. In my opinion, VM Limits will already have opened the playground far enough (in combination with CashTokens, Big Big Ints etc.) that protocol dev is not going to be a limiting factor on driving that building. At that point it’s much more on the developer tooling for higher layer, quality of wallet integrations (to drive interest and provide a starting point), effective media promotion, price action (up always drives interest) etc.

That’s just my take, which is why I’m more interested in protocol development moving into more “esoteric” features. The 2023 & 2025 upgrades have been big for enabling building, and I think to the extent we need more adoption (which we do) those problems now basically need to be addressed through other parts of the ecosystem.

But I agree the Loops idea does sound cool & might be quite significant on that front.

[lucasmcducas]

Which “esoteric” features are you referencing? I agree tooling has not caught up to our VM upgrades and that the VM isn’t the main thing holding us back anymore. I still feel we might as well continue focus on it for next upgrade cycle as I don’t see any other big changes that are close to reaching consensus. It’s also something on peoples minds still and we might as well stay a couple steps ahead of tooling if there’s a couple add ons that will provide even more future use cases. The main one at this time does seem to be Loops, followed by Shift ops.