CHIP-2025-05 Bitwise: Re-Enable Bitwise Operations

[bitjson]

Even with solutions for loops, functions, and longer contract lengths, many critical algorithms for financial and cryptographic applications remain relatively inefficient if arithmetic and logical bitwise shifts must be emulated.

The cost of an emulated shift can easily be >10x native shifts, creating significant complexity in contract design, waste in transaction sizes, and unnecessary validation in full nodes.

Re-enabling OP_LSHIFT and OP_RSHIFT has been raised many times since the 2018 opcode restoration (e.g. 2023, 2024), but uncertainty about VM limits and BigInt support made it difficult to evaluate implementation details.

With the 2025 upgrade now behind us, I think we should consider re-enabling the remaining bitwise operations in 2026: OP_INVERT, arithmetic bitwise shifts, and logical bitwise shifts.

If you have thoughts on this topic, I’d love to hear them.

[bitcoincashautist]

Yes please, it’s very annoying to miss basic operations present in most other programming languages

[cculianu]

I’m a big fan of this and can go ahead and do a quick proof-of-concept implementation in BCHN.

Just give me the list of op-code names and numeric values and I can whip together a WIP POC.

[2qx]

Big fan of this. I’ve looked to use these about a half dozen times.

[ShadowOfHarbringer]

If you have thoughts on this topic, I’d love to hear them.

You have my sword

[BitcoinCashPodcast]

Least controversial proposal ever?

Without even a full CHIP document.

My instinct is that yeah this makes sense.

[cculianu]

Yep, certainly not controversial. I like this proposal so much, I implemented a proof of concept here (after discussing the details with Jason):

Draft: Proof of Concept of addition bitwise VM op-codes (!1962) · Merge...

[ShadowOfHarbringer]

@cculianu

Yep, certainly not controversial. I like this proposal so much, I implemented a proof of concept here (after discussing the details with Jason):

Impressive, that was fast.

[tom]

@bitjson

I think we should consider re-enabling the remaining bitwise operations in 2026: OP_INVERT , arithmetic bitwise shifts, and logical bitwise shifts.

So, in the spirit of knowing where we come from and avoid the same mistakes.
LSHIFT was the main reason for removal of opcodes, it actually would make the full node crash when used in script. Common Vulnerabilities and Exposures - Bitcoin Wiki

The Internetz tell me that it was based on https://github.com/openssl/openssl/blob/master/crypto/bn/bn_shift.c#L104
so, hey, maybe that bug was there. So be careful. (cc: @cculianu)

[ABLA]

I would quote from Shadow as he already said what I wanted to say here

@ShadowOfHarbringer

Since we are touching consensus again, it would generally make most sense to collect up multiple of these math operations together and implement them as a single upgrade.

Dividing mutiple small simple changes between multiple upgrades will create chaos and increase implementation cost across the entire ecosystem.

I think we should collect all the OP_Code that already has a consensus and implement them in a single upgrade

CHIP 2025-05 Native Elliptic Curve Arithmetic Operations

Here are some other math operations that we could consider on top of ECADD and ECMUL. Opcode Description Benefit (vs. emulation) Cost to Emulate in Script Risk/Complexity Notes & Recommendation Basic Operations OP_ECADD Point addition: given two secp256k1 points P, Q on the stack, pushes P+Q. ≈ >1000× faster than doing field operations + curve math in script. ~ 4000+ big‑int ops + looping (~200 K “unit” ops) Moderate: must validate inputs lie on curve, constant‑time implementati…

[BitcoinCashPodcast]

@ABLA

I think we should collect all the OP_Code that already has a consensus and implement them in a single upgrade

Note that collecting together related upgrades into a “package” feels nice, but there’s no actual reason it has to be done that way. If a couple of upgrades make it in this year, or next year, and some others the year after or never - that’s fine. BCH is doing really well at just taking small iterative steps which stack up to cumulative and enormous results without needing to rush things.

[bitjson]

Thank you all for the responses! Pushed up an initial draft:

GitHub - bitjson/bch-bitwise: Re-enables bitwise operations, enabling Bitcoin...

Still reviewing some of the edge-case behaviors, but hopefully this is 80% of the way there.

Thank you @cculianu for powering out an implementation for BCHN and helping to clarify the spec!

If you’d like to experiment: a draft implementation for OP_INVERT , OP_LSHIFTNUM , OP_RSHIFTNUM , OP_LSHIFTBIN , and OP_RSHIFTBIN now work in Bitauth IDE (click here for a little playground):

[ShadowOfHarbringer]

@BitcoinCashPodcast

BCH is doing really well at just taking small iterative steps which stack up to cumulative and enormous results without needing to rush things.

Yeah, I did not mean to “rush” or anything like that.

Bundling together smaller upgrades into single bigger upgrade is just a matter of efficiency and decreasing overall implementation cost across the ecosystem.

When you have multiple tiny changes and you spread them all over multiple upgrades, this will effectively create more work for everybody and annoy lots of people.

If we are dealing with “tiny” things, it’s therefore more efficient to bundle.

[bitjson]

@tom

So, in the spirit of knowing where we come from and avoid the same mistakes.
LSHIFT was the main reason for removal of opcodes, it actually would make the full node crash when used in script.

And OP_RSHIFT too! But Satoshi just added a comment in the code (in Feb. 2010), he doesn’t seem to have realized it was also a consensus issue until late July 2010.

[cculianu]

Thanks for the warning, Tom. Indeed we don’t really depend on OpenSSL for this (or for much, really). I think we still only use openssl to provide a randomness source, and that’s it.

My personal view is openssl always was a problematic library – too many bugs for such a critical piece of infrastructure.