Re-enable remaining bitwise opcodes in 2026?

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.

9 Likes

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

8 Likes

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.

8 Likes

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

6 Likes

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

You have my sword :+1: :crossed_swords:

3 Likes

Least controversial proposal ever?

Without even a full CHIP document.

My instinct is that yeah this makes sense.

5 Likes

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

4 Likes

Impressive, that was fast.