Background

The Great Script Restoration (a group of BIPs including 440, 441, OP_TX, and some new opcodes being called Tapleaf 0xc2) should not be confused with the Great Consensus Cleanup (BIP 54)

I believe Rusty Russell has been working on the Great Script Restoration for at least two years (Shinobi was writing about this work in Bitcoin Magazine in May of 2024) and a few days ago, Russell and Julian Moik proposed a new iteration #1610402.

What it does

The Great Script Restoration is a soft fork. It requires some significant changes to Bitcoin, including turning back on a whole bunch of opcodes that were turned off by Satoshi back in 2010 -- mostly because of DDOS fears, I believe. Restoring these opcodes could allow many more types of spending policies and contracts on bitcoin, including things like:

• vaults
• covenants
• some of the quantum signature verification schemes

Russell and Moik reference five documents that specify the script restoration:

• BIP 440
• BIP 441
• OP_TX
• Extended Primitives
• Reusable Macros

In addition to added complexity, one of the big risks of the script restoration is that it might allow people to craft transactions for which verification is very resource intensive. They have a mitigation for this problem called the varops budget: "a simple, systematic and explicit cost framework for evaluating script operations based on stack data interactions, using worst-case behavior as the limiting factor."

The newest version of the Great Script Restoration looks like it suggests implementing all of the changes through a new Taproot leaf version so that most (all?) the other address types in Bitcoin would continue to function as normal.

Questions and Risks:

• Direction and risks: Whether this comprehensive consensus change is the right direction for Bitcoin, and whether the capabilities it adds outweigh its risks and potential negative consequences. MEV is often raised as one: if covenants enabled shared contracts whose outcome depends on transaction order, such as on-chain exchanges or auctions, miners might profit from ordering transactions, which would favor large and sophisticated miners.
• Segmented evaluation: Whether OP_SEGMENT, in which an OP_SUCCESS opcode affects only its own segment, is useful enough to add. It would let a covenant require a fixed prefix, such as a delay, ahead of script another party supplies in the same leaf.
• Arity opcode: Whether OP_MULTI, which lets the following opcode take a variable number of operands, is worth adding. It would let a script combine a large, variable number of values, such as input amounts.
• Amount accounting across inputs: Whether an opcode should let validation check the amounts that several inputs claim, as OP_CHECKCONTRACTVERIFY (BIP 443) and OP_VAULT (BIP 345) propose. Each input's script runs separately, so unless the scripts coordinate, one output can satisfy two inputs.

This seems like it adds quite a lot of complexity to Bitcoin. I wish that OP_TX was included on @1440000bytes' covenants support wiki. In the delving discussion about the Great Script Restoration, Russell notes that they designed the varops budget with a worst case scenario in mind, but a lot of the discussion was about to what extent the system might be abused.

There was some recent discussion on X where Moik posted about their recent work.

You can find the post about latest version of the Great Script Restoration on the Bitcoin Mailing List here and previous mailing list discussion here.

There is a reference implementation here: https://github.com/bitcoin-gsr/bitcoin/tree/gsr