The Great Script Restoration: Rusty Russell Proposes Varops Budget to Re-Enable Bitcoin Opcodes | Bitcoin Index

On March 14, 2026, Lightning Network developer Rusty Russell submitted a formal proposal to restore Bitcoin scripting capabilities that Satoshi Nakamoto disabled sixteen years ago. The two draft Bitcoin Improvement Proposals introduce a “varops budget” system designed to re-enable fifteen opcodes, massively expand stack limits, and return Bitcoin Script to something closer to its original vision, all without creating new denial-of-service vulnerabilities.

If activated, this would be the most significant expansion of Bitcoin’s programmability since Taproot.

The sixteen-year handicap

In August 2010, Satoshi released Bitcoin version 0.3.1, which disabled fifteen opcodes to address CVE-2010-5137, a vulnerability where operations on large numbers could consume excessive CPU time and memory during transaction validation. At the time, Bitcoin Script supported arbitrary-precision arithmetic using OpenSSL’s BIGNUM type. Operations like OP_MUL or OP_CAT on large operands could create transactions that were extremely expensive to validate, opening the network to denial-of-service attacks.

Satoshi also imposed a hard 520-byte limit on stack elements. These restrictions weren’t philosophical objections to programmability. Just two months before disabling the opcodes, Satoshi wrote on BitcoinTalk:

“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of.”

Script was supposed to be a general-purpose solution. The 2010 restrictions were a temporary patch until better resource constraints could be designed.

That “temporary” patch has lasted sixteen years.

Two BIPs, one foundation

Russell’s March 2026 submission proposes two interconnected BIPs:

BIP 1: Varops budget for script runtime constraint

This establishes a systematic cost accounting framework for script operations that deal with variable-length data.

Each transaction receives a varops budget equal to its weight multiplied by 10,000. Opcodes consume budget based on the byte-length of their operands, not their values. If a transaction exceeds its budget during validation, it fails.

The cost structure:

Signature operations: 500,000 units each
Hashing operations (SHA256): 50 units per byte hashed
OP_ROLL: 48 units per stack element moved
Fast operations (comparing bytes, zeroing, copying): 2 units per byte
Other operations: 4 units per byte output

The budget is transaction-wide rather than per-input, explicitly designed to support cross-input introspection where a small input might need to examine larger inputs elsewhere in the transaction.

BIP 2: Restoration of script capabilities (Tapscript v2)

This leverages the varops budget to restore pre-2010 scripting power via a new taproot leaf version: 0xc2.

What it re-enables:

15 previously disabled opcodes: OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT, OP_DOWNSHIFT, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD
Massively increased stack limits:
- Stack element size: 520 bytes → 4,000,000 bytes
- Total stack capacity: ~520,000 bytes → 8,000,000 bytes
- Maximum stack elements: 1,000 → 32,768
Unlimited-precision arithmetic (no more 31-bit restriction)
Unsigned-only integers (simplifies implementation)

Scripts using tapleaf version 0xc2 would be subject to varops budget constraints but would otherwise operate with pre-2010 expressive power.

Benchmarked on fourteen machines

Russell and co-author Julian Moik didn’t just propose cost numbers. They built a prototype implementation and benchmarked worst-case script execution across fourteen different machines spanning x86_64, ARM64, Linux, macOS, and Windows. Test systems ranged from Apple M-series chips to AMD Ryzen processors to Intel i5/i7/i9 CPUs, plus a Raspberry Pi 5 and an Intel N150 running on an Umbrel node.

The benchmark goal: ensure that a maximally-filled block using these restored opcodes would not take longer to validate than a maximally-filled block under current rules (which is dominated by 80,000 Schnorr signature validations, the per-block sigops limit).

According to the BIP, on all fourteen tested machines, the worst-case Great Script Restoration block validation time was below 1.0 times the current worst-case time. The varops budget successfully prevents the reintroduction of new denial-of-service vectors.

The raw benchmark data and analysis scripts are publicly available (last updated January 23, 2026).

Who is Rusty Russell?

Rusty Russell brings credibility from two decades of low-level systems work:

Linux kernel developer since the 1990s, known for writing ipchains, iptables, and rewriting the Linux module subsystem
First person to implement Lightning: switched to full-time Bitcoin work in 2015, authored the majority of the Lightning Network protocol specification
Core Lightning lead developer, one of the major Lightning implementations
Works at Blockstream

Russell’s dual background in kernel-level performance optimization and Bitcoin Layer 2 protocols gives him a unique perspective on both the computational constraints and the programmability requirements of Bitcoin Script.

The broader restoration project

The varops BIPs are part of a larger initiative Russell calls the Great Script Restoration, which he first outlined in January 2024. The project’s premise: Bitcoin’s scripting limitations have become a bottleneck for scaling and Layer 2 innovation.

As Russell told Bitcoin Magazine in May 2024:

“By pushing through and analyzing a comprehensive restoration of script as Satoshi initially designed it, we can actually try to explore the entire space of what functionality we need, rather than bickering and infighting over what small extension of functionality is good enough for now.”

In September 2025, Russell posted four draft BIPs to the Bitcoin-Dev mailing list as a package:

Varops budget
Script restoration via tapleaf 0xc2
OP_TX (transaction introspection opcode)
Miscellaneous new opcodes (OP_CHECKSIGFROMSTACK, OP_SEGMENT, OP_BYTEREV, etc.)

The March 2026 submission focuses on just the first two, the foundational framework and core opcode restoration, leaving introspection and additional opcodes for potential future proposals.

Why this matters for Bitcoin’s future

Bitcoin’s current scripting limitations force a stark trade-off: either accept the constraints and build simple contracts, or introduce trusted third parties and custodians. Lightning itself required three separate soft forks (CLTV, CSV, and SegWit) before it could even be implemented safely. More complex Layer 2 constructions like channel factories, timeout trees, or shared UTXOs with more than two participants are simply not possible without more expressive script capabilities.

The varops budget offers a systematic answer to the question that has stalled many previous proposals: how do we know this won’t create a new DoS vector? By establishing a clear cost model benchmarked against real hardware, it provides a framework that future proposals can build upon, whether or not the full Great Script Restoration is ever activated.

What’s not included (yet)

Notably absent from the March 2026 pull request, though present in the September 2025 mailing list version:

OP_TX (transaction introspection): would allow scripts to directly query parts of the spending transaction
OP_CHECKSIGFROMSTACK (CSFS): verify signatures against arbitrary data, not just transaction hashes
OP_TWEAKVERIFY: Schnorr public key arithmetic for cooperative exit scenarios
CTV/TXHASH equivalents: granular commitment to specific transaction fields

Russell appears to be pursuing a staged approach: establish the varops foundation first, then propose introspection and covenant opcodes as follow-on work.

The path ahead

As of March 15, 2026, Pull Request #2118 is open and under review. Bitcoin Core contributor Murch (Mark Erhardt) has left several technical comments on formatting and calculations in the BIP text. The proposals are explicitly marked Status: Draft with placeholder BIP numbers, awaiting formal assignment after initial review.

The reference implementation remains a prototype rather than a production-ready Bitcoin Core pull request. Discussion continues on the Delving Bitcoin forum and the Bitcoin-Dev mailing list.

This is a serious proposal with rigorous benchmarking behind it, from a developer with deep credibility. But re-enabling fifteen opcodes at once, even with solid resource constraints, will face “too much, too fast” objections from Bitcoin’s notoriously conservative development culture. The fact that this sat in mailing list limbo from September 2025 to March 2026 before getting a formal BIP pull request suggests the path to activation, if it happens at all, will be long.

Still, the varops framework itself might be the most durable contribution here. Even if the full restoration doesn’t happen, other BIPs could use this cost model to justify new opcodes or increased limits. And in a protocol as change-resistant as Bitcoin, simply demonstrating that Satoshi’s original scripting vision can be safely restored is an achievement worth recognizing.

Sources

Data/status as of March 14, 2026.