While the scope of proposals is quite broad, what might be the reason Rusty Russell’s “Great Script Recovery” is considered the forward path of Bitcoin development?

Block unicorn note: Rusty Russell is an active developer in the Bitcoin community and is highly respected within it. He has made remarkable contributions to Linux kernel development and has been involved in various Bitcoin Core development projects.

When Bitcoin was initially designed, it included a complete scripting language intended to cover and support any potential security use case users might propose in the future. As Satoshi Nakamoto stated before disappearing:

“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 transaction type I could think of, but in later versions, we removed the ability to run arbitrary scripts. The problem was that every feature required special support codes and data fields, whether they were used or not, which led to too many special cases. The solution was script, which generalized the problem so that transactions can describe their conditions in a way specific to them, and the network nodes can evaluate and validate these conditions.” - Satoshi Nakamoto, June 17, 2010

The whole purpose was to give users a language generic enough to allow them to organize their transaction types according to their wishes. In other words, it gives users the space to design and experiment with how they write their own money.

Before his disappearance, Satoshi Nakamoto removed 15 opcodes, disabling them completely, and added a hard limit on the size of data blocks that could operate on the script engine stack (520 bytes). This was because he effectively messed up, leaving behind many ways complex scripts could potentially be used to conduct DOS attacks on the entire network (sending large amounts of junk requests, causing network paralysis), creating huge and costly transactions that could crash nodes.

These opcodes were not removed because Satoshi Nakamoto deemed these functionalities as dangerous, or that people shouldn’t exploit them to build what they could, but simply (at least on the surface) because they posed a risk to the entire network without resource limitations, and thus might impose the worst verification costs on the network without restrictions.

Since then, every Bitcoin upgrade has ultimately been an optimization of the remaining features, correcting other less severe flaws left to us by Satoshi Nakamoto, and expanding the functionality of the subset of scripts we have left.

Great script recovery

At the Bitcoin++ conference in Austin in early May, core Lightning Network developer Rusty Russell made a very radical proposal in his first talk at the conference, where he basically proposed re-enabling most of the opcodes disabled by Satoshi Nakamoto before his disappearance in 2010.

Since the activation of Taproot in 2021 (Taproot is a significant upgrade to Bitcoin aimed at improving privacy, security, and scalability), the development field has been somewhat aimless. It is well understood that Bitcoin lacks sufficient scalability to truly provide sovereign services to any significant population in the world, or even to provide scalability in a minimally trusted or custodial manner that can surpass very large custodial institutions and service providers, and cannot truly escape the constraints of government oversight.

This article highlights an understanding at the technical level of Bitcoin, which is not a matter for debate. The debatable issue is how to address this deficiency, which is a very controversial topic. Since the proposal of Taproot, everyone has been proposing very narrow proposals aimed at solving problems that can only be achieved with specific use cases.

For example, ANYPREVOUT (APO) is a proposal that allows signatures to be reused across different transactions as long as the input scripts and amounts are the same. This proposal is specifically designed to optimize the Lightning Network and its multi-party versions. CHECKTEMPLATEVERIFY (CTV) is a proposal that requires coins to be spent only by transactions that exactly match predefined transactions. This proposal is designed to extend the functionality of pre-signed transaction chains by making them completely trustless. OP_VAULT is specifically designed to set a “timeout” for cold storage solutions so that users can “cancel” withdrawals from cold storage by sending them to colder multi-signature setups to prevent their keys from being leaked.

There are many other proposals, but I think you’ve understood the key points. Over the past few years, each proposal has been aimed at either slightly increasing scalability or improving a single small feature, as this was deemed desirable. This is why these discussions have not progressed. No one is satisfied with other proposals because they have not met the use cases they want to see.

Aside from the proposers, no one believes any proposal is comprehensive enough to be considered a reasonable next step.

This is the logic behind the “Great Script Recovery.” By advocating for and analyzing the comprehensive restoration of scripts, just as Satoshi Nakamoto originally designed, we can actually attempt to explore the entire functional space we need, rather than debating and quarreling over which small feature extension is good enough for now.

OPCODES (Operation Codes)

• OP_CAT: Get two data from the stack and add them to form one data.
• OP_SUBSTR: Accepts a length parameter (in bytes), gets a piece of data from the stack, removes the bytes of that length and puts them back on the stack.
• OP_LEFT and OP_RIGHT: Accepts a length parameter, takes a piece of data from the stack and removes bytes of the specified length from one side or the other of it.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT and OP_DOWNSHIFT: Accept a data element and perform the corresponding bit operation on it.
• OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, and OP_MOD: Mathematical operators for multiplication, division, and modulo operations (returning the remainder of division).

In addition to the opcodes listed above to recover, Rusty Russell proposed three additional opcodes designed to simplify the combination of different opcodes:

OP_CTV (or TXHASH/equivalent opcode): Allows fine-grained enforcement of certain parts of a transaction, requiring those parts to be exactly consistent with predefined content.

CSFS: Allows verification of signatures, not just the entire transaction, so that certain parts of the script or data used must be signed before they can be executed.

OP_TWEAKVERIFY: A Schnorr-based operation validation, involving public keys, such as adding or subtracting individual public keys from an aggregated public key. This can be used to ensure that when one party unilaterally spends from a shared unused transaction output (UTXO), funds from all other parties are sent to an aggregate public key that allows cooperative spending without requiring the signature of the party leaving the shared UTXO.

Why Are We Doing So?

Layer2 networks are essentially extensions of the Bitcoin base layer, and they are constrained by the functionalities of the base layer. Before the Lightning Network could be implemented, three separate soft forks were needed: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV), and Segregated Witness (SegWit).

Without a more flexible base layer, it is impossible to build more flexible Layer2 networks. The only shortcut is to trust third parties, which is very straightforward, but I hope we all aspire to remove trust in third parties as much as possible from every aspect of interacting with Bitcoin’s scalability.

We need to be able to do things that are currently impossible, such as safely consolidating two or more individuals into a single unused transaction output (UTXO) and being able to execute without trust on the base layer. The current flexibility of Bitcoin scripts is not sufficient. At the most basic level, we need contracts, and we need scripts to actually enforce finer details about executing transactions to ensure that a user securely exiting their own UTXO does not put other users’ funds at risk.

From a higher perspective, this is the functionality we need:

Introspection: We need to be able to actually inspect specific details about the spending transaction itself on the stack, such as “this portion of the money will flow to a particular public key of an output.” This allows me to use my own specific Taproot branch to extract my funds independently while ensuring that I cannot take anyone else’s funds. The executed script will ensure that the funds of other owners are sent back to addresses composed of other users’ public keys to prevent loss of funds caused by other participants.

Forward Data Carrying: Assuming we further develop the concept of a single UTXO with a large number of people, where anyone can freely enter and exit. In this case, we need a way to track who has how much money, typically using Merkle trees and their roots. This means that when someone exits, we must ensure that “records” who is entitled to receive what as part of the change UTXO of other people’s funds. This is essentially a specific use of introspection.

Public Key Modifying: We need to ensure that modifications to aggregated public keys can be verified on the stack. In a shared unspent transaction output (UTXO) scheme, our goal is to facilitate cooperation and efficient flow of funds through an aggregated public key containing all participants. When someone unilaterally exits the shared UTXO, we need to remove their individual public key from the aggregated public key. If all possible combinations were not precomputed, then the only option is to verify whether subtracting a public key from the aggregated public key would generate a valid public key composed of the remaining individual public keys.

Ensuring Security: As I mentioned above, the reason for disabling all these opcodes was to address DOS attacks (causing network crashes by sending large amounts of junk requests), which could lead to the crash of nodes forming the network. One way to address this issue is by limiting the amount of resources any of these opcodes can use.

When it comes to signature verification, the most expensive part of Bitcoin script, we already have a solution for this called the Signature Operation (sigops) budget. Each use of a signature checking opcode consumes a certain “budget,” i.e., the number of signature operations allowed per block, setting a hard limit on the cost required to validate a block for a transaction to a user. Taproot changes how this works by no longer using a single global block limit, but having each transaction have its own sigops (signature operations) limit, proportional to the size of the transaction. This essentially equals the same global limit but makes it easier to understand how many sigops each transaction has available.

The change in Taproot regarding the sigops (signature operations) limit for each transaction offers the possibility of a generalized approach, which is also the suggestion Rusty Russell proposed regarding varops limitations. The idea is to allocate a cost for each reactivated opcode to account for the worst-case scenario each opcode could create in terms of the most expensive computational cost during verification. Thus, each opcode will have its own “sigops” limit, limiting the amount of resources it can consume during verification. This will also be based on the size of any transactions using these opcodes, making it convenient for inference while still accumulating to the implicit global limit of each block. This will address DOS attacks (causing network crashes by sending large amounts of junk requests), which was also the reason Satoshi Nakamoto initially disabled all these opcodes.

The Driving Force Forward

I believe many of you might think, “That’s a big change.” I understand this perspective, but I think an important aspect to understand about a proposal is that we don’t have to do it all at once. The value of this proposal may not necessarily lie in fully restoring all these functionalities, but rather in us thoroughly examining a vast suite of foundational components and asking ourselves what functionalities we truly desire.

This would mark a complete shift from the past three years of arguing and debating, where we were merely debating minor, narrow changes, changes that only affected certain functionalities. It’s like a square where everyone can gather and collectively contemplate the direction of the future. Perhaps, in the end, we will restore all these functionalities, or perhaps we will only activate some, because consensus is about agreeing on which functionalities all of us believe need to be enabled.

Regardless of the ultimate outcome, this can be a change that positively impacts the entire dialogue about our future direction. We can actually map out and fully understand the situation, rather than groping forward when debating the next step on an obscure path.

This is by no means the only way forward that we must take, but I believe it presents the best opportunity for us to decide which path to take. It’s time to start working together again in a practical and effective manner.

Statement:

1. This article originally titled “伟大的脚本恢复：比特币的前进之路” is reproduced from [Block unicorn]. All copyrights belong to the original author [SHINOBI]. If you have any objection to the reprint, please contact the Gate Learn team, the team will handle it as soon as possible.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.