ORIGINAL AUTHOR: SHINOBI

Original compilation: Block unicorn

Despite the scope of the proposal, what is the reason why Rusty Russell's "great script recovery" could be the way forward for Bitcoin's development?

Block unicorn Note: Rusty Russell is an active developer in the Bitcoin community and is very respected in the community. He has worked extensively on Linux kernel development and has been involved in many long Bitcoin core development projects.

Bitcoin was originally designed to have a complete scripting language designed to cover and support any potential security use cases that users may come up with in the future. As Satoshi Nakamoto said before he disappeared:

"The essence of Bitcoin is that once version 0.1 is released, the core design is determined for the rest of the lifecycle. Therefore, I wanted to design it to support every possible trading type I could think of. The problem is that everything requires special support codes and data fields, whether used or not, which leads to longest special cases. The solution is a script that generalizes the problem so that both parties can describe their transactions with specific conditions that the Node network evaluates or validates based on those conditions." - Satoshi Nakamoto, June 17, 2010

His whole purpose is to give users a language that is common enough for them to organize their types of transactions as they wish. That is, shorts for users to design and experiment with how to write their own coins.

Before he disappeared, Satoshi Nakamoto removed 15 of these Operation Codes, disabled them entirely, and added a hard limit on the scripting engine stack that limited the size of the data blocks that could be manipulated (520 bytes). This is because he actually screwed up, leaving behind a lot of ways that complex scripts could be used to carry out DOS attacks on the entire network (sending a large number of spam requests, causing the network to go down), creating huge and costly transactions that would crash Nodes.

These Operation Codes weren't removed because Satoshi Nakamoto thought the features were dangerous or that people shouldn't use them to build something that could be achieved, but simply (at least on the surface) because of the risk they pose to the entire network without resource constraints, such as the worst validation costs they could impose on the network without limitations.

Since then, each upgrade of Bitcoin has ended up being a functional optimization of the remaining features, correcting other less serious flaws that Satoshi Nakamoto left us, and expanding the functionality of our remaining script subset.

Great script recovery

At the Austin Bitcoin++ conference in early May, core Lighting Network developer Rusty Russell made a very radical proposal in his first speech at the conference, where he basically came up with the idea of re-enabling the large longing Operation Code that Satoshi Nakamoto had disabled before it disappeared in 2010.

In the years since the activation of Taproot in 2021 (Taproot is a major upgrade to Bitcoin that aims to improve privacy, security, and scalability), the development space has actually been a bit aimless. We all know that Bitcoin is not scalable enough to truly provide self-sovereign services to any sizable size of the world's population, and may not even be able to provide scalability to service providers who can surpass very large custodians and service providers, and cannot truly break free from the long-arm constraints of governments, in a way that minimizes trust or custody.

This article points to the technical level of Bitcoin, which is not an issue to be debated. The question worth arguing about is how to fix this flaw, which is a very controversial topic. Since Taproot was introduced, everyone has been coming up with very narrow proposals that aim to solve problems that can only be achieved for specific use cases.

For example, ANYPREVOUT (APO) is a proposal that allows signatures to be reused in different transactions, as long as the script and amount entered are the same, and this proposal is specifically designed to optimize the Lighting Network and its longer versions. CHECKTEMPLATEVERIFY (CTV) is a proposal that requires hard coins to only be spent by transactions that exactly match predefined transactions, and 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 a cold storage solution, so that users can "unfetch" from cold storage by sending it to a colder long settings to prevent their Secret Key from being compromised.

There are longest other proposals, but I think you already get the gist. Over the past few years, each proposal has been designed to either slightly increase scalability or improve a single small feature, as this is considered desirable. That is the root cause of why these discussions have not made progress. No one was happy with the other proposals because they didn't meet the use cases they wanted to see.

No one other than the sponsor of the proposal believes that any proposal is comprehensive enough to be considered a reasonable next step.

This is the logic behind "Great Script Recovery". By pushing and analyzing a full recovery of scripts, as Satoshi Nakamoto originally designed, we can actually try to explore the entire feature shorts we need, rather than arguing and infighting about which small feature extensions are good enough right now.

OPCODES (Operation Code)

• OP_CAT: Takes two pieces of data from the stack and adds them together to form one data.
• OP_SUBSTR: Accept a length parameter (in bytes), get a piece of data from the stack, remove the bytes of that length and put it back on the stack.
• OP_LEFT and OP_RIGHT: Accepts a length parameter that takes a piece of data from the stack and removes bytes of the specified length from one side or the other.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT, and OP_DOWNSHIFT: Accepts a data element and performs the corresponding bit operations on it.
• OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV, and OP_MOD: Math operators for multiplication, division, and modulo operations (returning the remainder of the division).

In addition to the above list of Operation Codes to recover, Rusty Russell proposes three more Operation Codes designed to simplify the combination of different Operation Codes:

OP_CTV (or TXHASH/ equivalent Operation Code): Allows fine-grained enforcement of certain parts of a transaction that must be exactly as predefined.

CSFS: Allows signatures to be verified, not just for the entire transaction, which requires that certain parts of the script or the data used must be signed in order to be executed.

OP_TWEAKVERIFY: Validates Schnorr-based operations that involve Public Key, such as adding or subtracting individual Public Key from the aggregate Public Key. This can be used to ensure that when one party unilaterally leaves a shared unused transaction output (UTXO), all other participants' funds are sent to an aggregated public key that does not require the signing of the departing party to make cooperative spending.

Why are we doing this

Layer 2 networks are essentially extensions of Bitcoin's base layer, and they are functionally constrained by the functions of the base layer. Lighting Network requires three separate Soft Fork before they can actually be implemented: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv), and SegWit (Segregated Witness).

Without a more flexible base layer, you can't build a more flexible layer 2 network. The only shortcut is to trust third parties, which is very simple and straightforward, and I hope we all aspire to remove trusted third parties from every aspect of interaction with Bitcoin at scale as much as possible.

We need to be able to do something that is not currently possible in order to securely merge more than two people into a single unused transaction output (UTXO) and be able to perform trustlessly on the base layer. Bitcoin Script's current flexibility is not enough. At the most basic level, we need contracts, and we need scripts that can actually enforce finer details about executing transactions to ensure that a user safely exiting their own UTXO doesn't put other users' funds at risk.

On a higher perspective, this is what we need:

Introspection: We need to be able to actually check specific details on the stack about the spending transaction itself, such as "this amount of money will go to this public key of some output". This allows me to withdraw my funds on my own using my own specific Taproot branch, while ensuring that I can't withdraw anyone else's funds. The executed script will ensure that the funds of other owners are sent back to the Address consisting of the Public Key of other users, in case other participants cause loss of funds.

Forward Data Carrying: Let's say we take the concept of a single UTXO, for example, with a large number of people, that anyone can come and go as they please. In this case, we need a way to track who has longest or less money, usually using the Merkle Tree and its roots. This means that when someone leaves, we have to make sure to "record" who is entitled to what as part of the change UTXO for everyone else's funds. This is basically a specific use of introspection.

Public Key Modification: We need to ensure that modifications to the aggregate Public Key can be verified on the stack. In the Unused Transaction Output (UTXO) sharing scheme, our goal is to facilitate cooperation and efficient flow of funds through an aggregated Public Key that includes all participants. When someone unilaterally leaves a shared UTXO, we need to remove their personal Public Key from the aggregate Public Key. If all possible combinations are not calculated beforehand, the only option is to verify that subtracting one public key from the aggregate public key will produce a valid public key consisting of the remaining individual public keys.

How to be safe: VAROPS As I said above, the reason for disabling all these Operation Codes is to address DOS attacks (which cause the network to crash by sending a large number of spam requests), which can cause the Nodes that make up the network to crash. One way to solve this problem is to limit the amount of resources that can be used by any of these Operation Codes.

When it comes to signature verification, the most expensive part of the Bitcoin script, we already have such a solution, which is called the signature operation (sigops) budget. Each use of the signature check Operation Code consumes a certain "budget", that is, the number of signature operations allowed per block, which sets a hard limit on the cost that a transaction can generate to validate a block.

Taproot changes this way of working, no longer using a single global Block limit, but instead each transaction has its own sigops (signature operation) limit, proportional to the size of the transaction. This basically equals the same global limit, but it's easier to understand that each transaction has long less sigops available.

The change in Taproot's sigops (signature operation) limit for processing each transaction opens up the possibility of a generalization approach, which is what Rusty Russell suggested in terms of varops limits. The idea is to assign a cost to each reactivated Operation Code to account for the worst-case scenario that each Operation Code may create, i.e., the most expensive computational cost incurred at the time of validation. In this way, each Operation Code will have its own "sigops" limit, limiting the amount of resources it can consume during the validation process. This will also be based on the size of any transactions that use these Operation Code, so inference can be facilitated while still accumulating to the implicit global limit per Block.

This would solve the DOS attack (by sending a lot of spam requests, causing the network to crash) because of these spam transactions, and what caused Satoshi Nakamoto to initially disable all those Operation Codes.

Momentum to move forward

I'm sure longest of you will think, "This is too much change." I can understand that, but I think an important aspect to understand as a proposal is that we don't have to do it all. The value of this proposal isn't necessarily that all of these features are fully restored, but that we're going to take a holistic look at a vast suite of foundational components and ask ourselves what we really want in terms of functionality.

It would be a complete shift from the last three years of bickering and debating that we have only been arguing about small narrow changes that only have certain functions. It's like a square where everyone can come together and look at the direction of the future. Maybe we'll eventually restore all of these features, or maybe we'll end up activating just a few of them, because the Consensus is that these are the ones that we all agree need to be turned on.

Regardless of the end result, this can be a change that positively impacts the entire conversation about our future direction. We can actually map out and get a full picture of the situation, rather than groping our way around debating which murky route to take next.

It's by no means the path we have to take, but I think it's the best chance for us to decide which route we want to take. It's time to start working together again in a practical and productive way.