Rusty Russell Proposes Two BIPs to Restore Disabled Bitcoin Script Opcodes | Bitcoin Index

For 16 years, Bitcoin’s scripting language has operated under emergency restrictions. In July 2010, Satoshi Nakamoto disabled 15 opcodes to patch a vulnerability that could enable denial-of-service attacks. Those restrictions worked, but they also gutted Bitcoin’s programmability. On March 8, 2026, Core Lightning creator Rusty Russell and Julian Moik submitted two draft Bitcoin Improvement Proposals to finally restore what was lost.

This isn’t a minor tweak. The proposals re-enable all 15 disabled opcodes, increase the maximum stack element size from 520 bytes to 4 megabytes, and introduce a computational budget system that prevents attacks without arbitrary limits. If adopted, Bitcoin Script becomes a legitimate programming environment again.

Who is Rusty Russell?

Russell is a rare breed: someone who earned credibility in both the Linux kernel community and Bitcoin development. He spent over two decades working on the Linux kernel, writing foundational networking tools like iptables and ipchains, and rewriting the kernel module subsystem. In 2015, he shifted to Bitcoin full-time and became the first person to implement a Lightning Network prototype. He chaired the Lightning Protocol specification effort for several years and currently works on Core Lightning, one of the three major Lightning implementations.

When Russell proposes something, people pay attention. This proposal is no exception.

The two BIPs

BIP 1: Varops budget

The first proposal establishes a computational cost framework called the “varops budget” (variable operations budget). Every transaction gets a budget equal to its weight multiplied by 10,000. Opcodes consume budget based on the length of their stack operands, not their values. Exceed the budget, and the transaction fails validation.

This approach replaces the old strategy of banning risky opcodes outright. Instead, every operation has a cost. Signature checks cost 500,000 units. Hashing costs 50 units per byte. Copying operations cost 3 units per byte. A 1,000-byte transaction (4,000 weight units) gets a budget of 40 million units, enough for 80 signature checks or 13,333 concatenation operations on 1 KB elements.

The costs weren’t pulled from thin air. Russell and Moik benchmarked worst-case scripts across 14 machines, including Apple M1/M2/M4, AMD Ryzen chips, Intel processors, and a Raspberry Pi 5. On every tested machine, the worst-case execution time with the new opcodes was below the pre-restoration worst case. The new opcodes don’t introduce new performance bottlenecks.

BIP 2: Script restoration

The second proposal re-enables the 15 disabled opcodes and removes restrictive limits, using the varops budget as the safety mechanism. The changes are dramatic:

Stack limits:

Maximum stack element size: 520 bytes → 4,000,000 bytes
Total stack byte limit: none → 8,000,000 bytes
Maximum stack elements: 1,000 → 32,768
Numerical value size: 31 bits → unlimited

15 re-enabled opcodes:

Splice: OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT
Bit operations: OP_INVERT, OP_AND, OP_OR, OP_XOR
Bit shifts: OP_UPSHIFT, OP_DOWNSHIFT
Arithmetic: OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD

The proposal also makes a philosophical shift: all numbers are now treated as unsigned integers. Negative numbers are gone. This simplifies arbitrary-precision arithmetic and avoids the awkwardness of sign bits in variable-length representations. Three opcodes incompatible with unsigned arithmetic (OP_1NEGATE, OP_NEGATE, OP_ABS) become immediate-success opcodes.

Why 16 years?

In July 2010, Bitcoin was still in its infancy. The script interpreter had multiple bugs (including the “1 RETURN” bug fixed just 15 days earlier), and the disabled opcodes could be exploited for denial-of-service attacks. Satoshi’s fix was blunt but effective: disable the risky opcodes and impose strict stack limits.

The problem is that those emergency measures became permanent. For 16 years, developers wanting to implement complex spending conditions have had to work around 520-byte limits and missing opcodes. Covenants, vaults, and advanced multisig schemes either required trusted third parties or weren’t possible at all.

The restoration is feasible now because Bitcoin has matured. Segregated Witness (2017) introduced weight-based transaction limits. Taproot (2021) introduced tapscript with versioned leaves, making it safe to add new script versions. BIP-342’s sigops budget showed that per-transaction computational budgets work. The varops proposal generalizes that approach to all operations, not just signatures.

What this enables

With script restoration, Bitcoin scripts can finally do things that have been impossible for 16 years:

Enforce covenant conditions: Require outputs to pay to specific scripts or amounts
Implement vaults: Allow fund recovery paths with time delays and backup keys
Build complex multisig: n-of-m signatures with spending limits and fallback conditions
Verify zero-knowledge proofs: Large stack elements allow cryptographic verification on-chain
Create stateful contracts: Track balances or state across transactions

The 4 MB stack element limit is deliberate. As the BIP notes, “putting the entire transaction on the stack is a foreseeable use case.” Since blocks can be up to 4 MB in weight, allowing 4 MB stack elements makes sense for introspection scripts that need to process complete transactions.

This proposal is part of a broader four-BIP series Russell announced on the Bitcoin-Dev mailing list in September 2025. The first two BIPs provide the foundation; the latter two (OP_TX for transaction introspection and new opcodes like OP_CHECKSIGFROMSTACK) build advanced covenant capabilities on top.

The path forward

The proposals are thorough. Over 590 lines of specification, extensive benchmarking, a reference implementation in progress, and six months of informal mailing list discussion since September 2025. But thoroughness doesn’t guarantee adoption.

Bitcoin’s consensus culture is conservative, and for good reason. Soft forks are permanent. Even narrower proposals like standalone OP_CAT have been debated for years without resolution. Russell’s proposal restores fifteen opcodes and removes multiple limits. That’s a big ask.

The question is whether Bitcoin’s culture can accept something this ambitious. If you’re going to soft fork anyway, maybe restoring everything at once with a solid safety mechanism makes sense. Or maybe the scope will fracture consensus and nothing happens. Galaxy Research predicted in 2025 that either OP_CAT or OP_CTV would achieve consensus in 2025, though implementation could take 1-2 years. We’re now in March 2026, and neither has activated. The Great Script Restoration might be even harder to push through.

But here’s my take: if Bitcoin Script stays frozen, alternative chains with more expressive smart contract capabilities will continue to siphon developer mindshare. Bitcoin’s security model is unmatched, but programmability matters. Developers will only tolerate working around 520-byte limits for so long before they build elsewhere. The varops approach is methodical, well-tested, and conservative in the right ways. It deserves serious consideration.