The Great Script Restoration: Bitcoin's Path to Richer Spending Conditions

In the summer of 2010, Satoshi Nakamoto quietly disabled fifteen operations from Bitcoin Script. The move patched a class of denial-of-service vulnerabilities, but it also froze Bitcoin's on-chain programmability at a rudimentary level. Sixteen years later, the debate over whether to restore those capabilities has become the central question of Bitcoin protocol development. The Great Script Restoration (GSR), proposed by Rusty Russell in May 2024, offers one answer: re-enable nearly everything Satoshi turned off, but with a new safety mechanism that prevents the original attacks.

This article examines why the opcodes were disabled, what restoring them would unlock, and how the GSR compares to narrower proposals like OP_CAT and OP_CTV. The stakes are high: the outcome determines whether Bitcoin can support covenants, vaults, and richer spending conditions natively, or whether those features remain the domain of Layer 2 protocols and sidechains.

Why Satoshi Disabled the Opcodes

Bitcoin Script was originally more expressive than it is today. The early versions included string manipulation (OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT), bitwise logic (OP_AND, OP_OR, OP_XOR, OP_INVERT), arithmetic (OP_MUL, OP_DIV, OP_MOD, OP_2MUL, OP_2DIV), and bit shift operations (OP_LSHIFT, OP_RSHIFT). In total, fifteen computational opcodes plus three version-control opcodes (OP_VER, OP_VERIF, OP_VERNOTIF) were disabled across Bitcoin versions 0.3.5 and 0.3.6, released in late July and August 2010.

The trigger was CVE-2010-5137: a crash bug in OP_LSHIFT demonstrated on the test network on July 28, 2010. More critically, researchers realized that without stack element size limits, a script combining OP_DUP and OP_CAT in a loop could double the size of a stack element on each iteration. After roughly 40 iterations, this would produce a value exceeding one terabyte, enough to crash any node on the network.

Rather than implement per-opcode size limits (which would have required careful analysis of every operation's worst case), Satoshi took the conservative path: disable everything that could contribute to resource exhaustion. It was an emergency fix, not a considered design decision. And it worked. But the disabled opcodes never came back.

The cost of caution: Satoshi's 2010 fix was the right call for a nascent network with no formal security review process. But it left Bitcoin Script in a state where you cannot multiply two numbers, concatenate two byte strings, or perform bitwise operations: capabilities that even the most constrained smart card environments support.

What Was Lost: The Disabled Opcodes

Understanding what the Great Script Restoration proposes requires knowing exactly what was removed. The disabled opcodes fall into four families.

The remaining active arithmetic opcodes (OP_ADD, OP_SUB, OP_NUMEQUAL, and a few others) are further limited to 32-bit integers. Since satoshi values can require up to 51 bits, this means Bitcoin Script cannot even perform basic math on its own denomination. You cannot write a script that divides a UTXO's value in half and sends each portion to a different address: not because the concept is complex, but because the arithmetic literally cannot represent the numbers involved.

The Great Script Restoration Proposal

Rusty Russell, a longtime Blockstream developer and Core Lightning contributor, unveiled the Great Script Restoration at the Bitcoin++ conference in Austin, Texas in May 2024. Rather than debating individual opcodes one at a time, Russell proposed restoring most of the disabled operations in a single soft fork, protected by a new safety mechanism called the varops budget.

BIP 440: The Varops Budget

The varops budget, formalized as BIP 440, assigns a computational cost to each reactivated opcode based on its worst-case validation expense. This works similarly to how the existing sigops limit constrains signature verification operations: every script gets a budget, and each operation consumes a portion of it. A script that tries to use OP_CAT in a resource-exhaustion loop would exceed its varops budget and fail validation before consuming meaningful resources.

The design insight is that the 2010 disabling was a blunt instrument. Individual opcodes are not inherently dangerous: what matters is the total computational cost of validating a script. By bounding that cost explicitly, you can safely re-enable operations that were disabled purely because no cost-accounting framework existed.

BIP 441: Tapleaf Version 0xC2

BIP 441 defines the actual restoration. It introduces a new Tapscript leaf version (0xC2) that restores Bitcoin Script to its pre-v0.3.1 capabilities. Key changes include:

• Re-enabling 15 disabled computational opcodes (the three version-control opcodes remain disabled as they serve no scripting purpose)
• Increasing the maximum stack object size from 520 bytes to 4,000,000 bytes (constrained by the varops budget)
• Restoring splice, bitwise, shift, multiply, and divide operations

Both BIPs were assigned their numbers in approximately March 2026 and published in April 2026. Julian Moik has been a key contributor continuing the development work. As of October 2026, both remain in Draft status.

The Individual Opcode Proposals

The GSR is not the only path forward. Several proposals target individual opcodes or small bundles. Understanding these is essential because the activation debate is partly about whether Bitcoin should adopt capabilities one at a time or in a coordinated restoration.

OP_CAT (BIP 347)

OP_CAT concatenates two stack elements into one. It sounds simple, but concatenation is a powerful primitive. By joining data fragments on the stack and then hashing the result, scripts can reconstruct and verify parts of the transaction they are embedded in. This enables covenants: spending conditions that restrict not just who can spend, but what the spending transaction looks like.

Authored by Ethan Heilman and Armin Sabouri (first proposed on the Bitcoin-Dev mailing list in 2023, assigned BIP 347 in April 2024), OP_CAT would be activated as a Tapscript-only soft fork by redefining OP_SUCCESS126. The specification reached "Complete" status on March 1, 2026. It has been tested extensively on Bitcoin Inquisition's signet, accumulating approximately 74,000 transactions.

OP_CAT's appeal lies in its generality. Combined with existing opcodes, it can construct recursive covenants (where spending conditions perpetuate across an unlimited chain of transactions), verify Merkle proofs on the stack, and even enable rudimentary zero-knowledge proof verification. Critics argue this generality is also its risk: OP_CAT opens a design space so large that its consequences are difficult to fully anticipate.

OP_CTV / CheckTemplateVerify (BIP 119)

OP_CTV, authored by Jeremy Rubin and first formally specified as BIP 119 in January 2020, takes the opposite approach: deliberately limited, non-recursive covenants. A CTV script commits to a hash of the spending transaction's template (outputs, version, locktime, and sequences). The spending transaction must exactly match.

This enables congestion control (batching many payments into a single on-chain commitment), simple vaults with time-delayed withdrawals, and more efficient constructions for payment channels and Layer 2 protocols. CTV is intentionally limited: you cannot build recursive covenants or general-purpose computation with it alone.

In February 2026, a new CTV activation client was published with BIP 9 deployment parameters: a 90% miner signaling threshold (1,815 of 2,016 blocks), with a signaling window opening March 30, 2026 and timing out March 30, 2027. As of October 2026, miner signaling stands at 0%. No blocks have signaled support.

OP_CHECKSIGFROMSTACK (BIP 348)

OP_CHECKSIGFROMSTACK (CSFS), authored by Brandon Black and Jeremy Rubin as BIP 348, enables signature verification against arbitrary data rather than just Bitcoin transactions. Where OP_CHECKSIG can only verify that a signature commits to the current transaction, CSFS reads a public key, a message, and a signature from the stack and verifies the signature against that message.

This is critical for oracle-based contracts: an oracle can sign a data payload (a price feed, an event outcome, an attestation), and the script can verify that signature without the oracle needing to interact with the Bitcoin transaction itself. Combined with CTV, CSFS can emulate SIGHASH_ANYPREVOUT, enabling LN-Symmetry (formerly eltoo) for cleaner Lightning channel state management without penalty transactions.

OP_TXHASH (BIP 346)

OP_TXHASH, authored by Steven Roose and Brandon Black as BIP 346, pushes a hash of selected transaction fields onto the stack. Its innovation is the TxFieldSelector: a variable-length byte sequence where individual bits specify which transaction fields are included in the hash. This allows scripts to commit to specific parts of a spending transaction with granularity that CTV's all-or-nothing template hash cannot match.

OP_TXHASH can be understood as a generalization of CTV. Where CTV commits to a fixed template, TXHASH lets you selectively commit to input values, output values, sequences, or any combination. This enables equality checks between inputs and outputs (useful for enforcing fee limits), in-band fee adjustment without anchor outputs, and custom signature commitment patterns.

64-Bit Arithmetic

Chris Stewart has authored a draft BIP (not yet assigned a number) to upgrade Bitcoin's existing arithmetic opcodes from 32-bit to 64-bit values. The current 32-bit limit means Script can represent integers up to roughly 2.1 billion, while satoshi values can reach 2,100,000,000,000,000 (21 million BTC in satoshis), requiring up to 51 bits. Any script that needs to do math on transaction amounts must work around this limitation with awkward multi-step constructions.

Upgrading to 64-bit arithmetic is a prerequisite for many covenant constructions that need to enforce value-based spending conditions. The proposal uses the compactSize data format already present in Bitcoin's serialization, keeping the change minimal.

What These Opcodes Enable Together

Individual opcodes are useful. In combination, they unlock entirely new categories of spending conditions that Bitcoin cannot currently express.

Vaults

Vaults (formalized as BIP 345 by James O'Beirne and Greg Sanders) enforce a mandatory delay before coins can be spent to an arbitrary destination while preserving a pre-specified recovery path. If your keys are compromised, you have a time window to redirect funds to cold storage. OP_VAULT depends on CTV (or TXHASH) to define the spending template and supports batching, partial unvaultings, and recursive deposits.

Covenants and Recursive Covenants

A covenant restricts how a UTXO can be spent: not just who can spend it, but what the spending transaction looks like. Non-recursive covenants (achievable with CTV alone) can enforce a single set of conditions. Recursive covenants (requiring OP_CAT or similar) can perpetuate conditions across an unlimited chain of transactions, enabling constructions like on-chain autonomous agents and perpetual fee-paying UTXOs.

Improved Discreet Log Contracts

Discreet Log Contracts (DLCs) currently require enormous numbers of pre-signed transactions to cover every possible outcome. With covenant opcodes, DLC construction could see efficiency improvements, as on-chain scripts can directly enforce outcome-dependent spending conditions without pre-computing every branch.

LN-Symmetry and Better Payment Channels

CTV combined with CSFS can emulate SIGHASH_ANYPREVOUT, enabling LN-Symmetry: a cleaner Lightning channel update mechanism that eliminates penalty transactions and toxic state. This simplifies Lightning implementations significantly and reduces the risk of losing funds due to outdated state broadcasts.

Joinpools and Shared UTXOs

Covenant opcodes enable constructions where multiple users share a single UTXO with individually enforceable exit rights. Protocols like Ark depend on some form of covenant to reach their full potential. Without covenants, shared UTXO constructions require interactive signing ceremonies that limit scalability.

Comparing the Approaches

The Bitcoin developer community is not debating whether to add new capabilities: the disagreement is over scope, risk, and sequencing. Four distinct approaches have emerged.

The Case for Minimalism (CTV + CSFS)

On June 9, 2025, an open letter signed by 66 signatories (led by James O'Beirne) called on Bitcoin Core contributors to prioritize review and integration of CTV and CSFS within six months. The argument: these two opcodes are the most reviewed, the most conservative, and together they enable the highest-value applications (vaults, LN-Symmetry, joinpools, congestion control). Start with what is well understood, and add more later if needed.

Critics of the letter, including Bitcoin Core contributor Antoine Poinsot, pushed back on the six-month timeline, arguing that the development stall reflects genuine technical disagreement rather than apathy. Setting deadlines on consensus changes risks pressuring reviewers into approving code they have not fully evaluated.

The Case for OP_CAT

OP_CAT proponents argue that a single general-purpose opcode is better than a collection of special-purpose ones. Concatenation combined with existing hashing and signature opcodes can replicate most of what CTV, CSFS, and TXHASH do individually, while also enabling capabilities none of them can match (recursive covenants, on-stack Merkle proof verification, rudimentary ZK verification).

The counterargument is that OP_CAT's generality is precisely the problem. It opens a design space so large that analyzing all possible uses and abuses is impractical. Recursive covenants, in particular, raise concerns about fungibility: if spending conditions can propagate indefinitely, UTXOs could become encumbered in ways that make them less interchangeable.

The Case for the Great Script Restoration

Russell's GSR reframes the debate entirely. Instead of asking "which specific opcode should we activate next?" it asks: "why are we artificially constraining Script when we have the tools to make it safe?" The varops budget provides a principled, general-purpose answer to resource exhaustion concerns. If the budget is correctly calibrated, then every opcode within it is safe by construction, and the community can stop relitigating individual opcodes.

The risk is scope. A 15-opcode restoration is a large change with a correspondingly large review surface. Even with the varops budget, each restored opcode creates new composition possibilities that must be analyzed. Proponents argue this is a one-time cost that avoids the death of a thousand cuts: years of sequential opcode debates, each consuming community attention and delaying progress.

Adam Back's perspective: The Blockstream CEO has backed covenant opcodes as a potential "last soft fork" for Bitcoin, arguing that covenant tools plus formal verification could make Script safe enough to reduce the need for repeated protocol upgrades. This framing resonates with the GSR philosophy of a comprehensive, one-time restoration.

The Activation Problem

Bitcoin's last consensus change was Taproot, activated in November 2021. As of October 2026, this is the longest period without a consensus change in Bitcoin's history: nearly five years. The stall is not purely technical.

The activation debate has become a political as well as technical process. The CTV activation client's 0% miner signaling demonstrates the challenge: even a well-reviewed proposal with an activation mechanism deployed cannot achieve consensus without broad community agreement that it should be the next change. Miners are reluctant to signal for any proposal that lacks clear community support, and the community is fragmented across the four approaches described above.

This creates a deadlock. CTV proponents argue their proposal is the most ready. OP_CAT proponents argue it is more general. LNHANCE proponents argue it is more targeted. GSR proponents argue the incremental approach is the problem itself. Each camp's existence gives the others a reason to wait.

The Ossification Question

Underlying the activation debate is a deeper question about Bitcoin's ossification. Some participants believe Bitcoin's consensus rules should change rarely if ever, and that the difficulty of activation is a feature, not a bug. Others argue that ossifying Bitcoin without covenant capabilities permanently limits its utility and pushes innovation to less secure environments. The GSR can be read as a response to this tension: restore everything at once, so the community never needs to have this debate again.

Implications for Layer 2 Protocols

The covenant debate is not abstract for Layer 2 builders. Every Bitcoin L2 operates within the constraints of what Script can verify. More expressive Script means more can be enforced on-chain, which directly affects trust models.

Lightning Network

LN-Symmetry (via CTV + CSFS emulating ANYPREVOUT) would eliminate penalty transactions, simplify channel state management, and reduce the risk of losing funds from broadcasting outdated states. This is one of the most cited use cases for covenant opcodes and has broad support across all four approaches.

Ark and Joinpools

Ark and similar joinpool constructions benefit enormously from covenants. Without them, shared UTXO management requires complex interactive protocols. With even basic covenants (CTV-level), exit conditions can be enforced non-interactively, improving both scalability and user experience.

Spark and Statechains

Spark currently operates on a 1-of-n trust model where at least one statechain operator must behave honestly during each transfer. Richer Script capabilities could strengthen this model by enabling more expressive on-chain verification of statechain transfers. Specifically, covenant opcodes could allow construction of spending conditions that enforce correct state transitions directly in Bitcoin Script, potentially enabling trustless dispute resolution without relying solely on operator honesty. While Spark functions well within today's Script constraints, covenant-powered spending conditions represent a path toward reducing trust assumptions further.

BitVM and Zero-Knowledge Proofs

BitVM currently achieves verification of arbitrary computation on Bitcoin through an elaborate challenge-response protocol. OP_CAT (or the full GSR) would significantly simplify these constructions by allowing on-stack data manipulation that BitVM must currently achieve through combinatorial explosion of Taproot leaves. ZK proof verification on Bitcoin, while theoretically possible today via BitVM, becomes dramatically more practical with OP_CAT-level expressiveness.

Timeline and Current Status

As of October 2026, no covenant proposal has been activated on Bitcoin mainnet. Here is where each stands.

What Happens Next

The covenant debate will resolve in one of three ways. First, a single proposal could achieve sufficient community and miner consensus to activate: CTV + CSFS is currently the frontrunner for this path, though its 0% signaling rate suggests activation is not imminent. Second, a broader package (LNHANCE or GSR) could build momentum as the community tires of incremental debates. Third, the deadlock could persist, and Bitcoin's Script capabilities remain frozen indefinitely.

For developers building on Bitcoin today, the practical implication is that covenant capabilities should not be assumed. Layer 2 protocols like Spark, Lightning, and Ark must work within current Script constraints while remaining architecturally ready to take advantage of new opcodes if they activate. Developers interested in building with these future capabilities can experiment on Bitcoin Inquisition's signet, where OP_CAT and CTV are both available for testing.

For a deeper look at how Spark works within today's Script constraints while supporting Bitcoin, stablecoins, and tokens, explore the Spark developer documentation and SDK. To see how the covenant debate connects to broader activation politics, read our analysis of the covenant activation path forward.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.