Since the Taproot upgrade in 2021, Bitcoin development has lacked direction, with proposals only addressing specific issues and failing to significantly improve scalability and self-sovereign service capabilities. The “Great Code Recovery” may be the way forward for Bitcoin development. This article is sourced from SHINOBI and compiled, translated, and written by Block Unicorn.
Table of Contents:
The Great Script Recovery
OPCODES
Why are we doing this?
Introspection
Forward Data Carrying
Public Key Modification
How to ensure security?
The driving force for progress
Although the proposed scope is quite broad, what is the reason why Rusty Russell’s “Great Code Recovery” may be the way forward for Bitcoin development?
Note: Rusty Russell is an active developer in the Bitcoin community and highly respected. He has made significant contributions to Linux kernel development and has been involved in many Bitcoin core development projects.
When Bitcoin was initially designed, it had a complete scripting language aimed at covering and supporting any potential security use cases that users might propose in the future. As Satoshi Nakamoto said before disappearing:
“His entire purpose was to give users a language powerful enough to organize their transaction types as they wished. That is, to give users the space to design and experiment with how to write their own currency.”
Before his disappearance, Satoshi Nakamoto removed 15 opcodes, completely disabling them, and added a hard limit on the data block size (520 bytes) that could be operated on the script engine’s stack.
This was because he actually messed up, leaving behind a way for complex scripts to potentially be used to launch a Denial of Service (DoS) attack on the entire network, creating huge and costly transactions that could crash nodes.
These opcodes were not removed because Satoshi Nakamoto believed these features were dangerous or that people should not utilize them to build what they could achieve. It was purely (at least seemingly) due to the risk they posed to the entire network without resource restrictions, resulting in the worst possible validation cost they could impose on the network without restrictions.
Since then, every Bitcoin upgrade has ultimately been an optimization of the remaining functionalities, correcting other less severe flaws left by Satoshi Nakamoto, and expanding the capabilities of the remaining subset of script commands.
At the Bitcoin++ conference in early May, Lightning Network core developer Rusty Russell proposed a very radical idea in his first presentation at the conference. He essentially proposed the idea of reenabling most of the code disabled by Satoshi Nakamoto before his disappearance in 2010.
Since the activation of Taproot in 2021 (an important Bitcoin upgrade aimed at improving privacy, security, and scalability), the development field has actually been somewhat aimless.
We all know that Bitcoin lacks sufficient scalability to truly provide self-sovereign services for any significant population in the world. It may even be unable to provide scalability in a minimally trusted or custodial manner that can surpass very large custodians and service providers, without truly escaping the constraints of government enforcement on service providers.
This article points out the understanding of Bitcoin’s technological aspects, which is not a topic that needs to be debated. The debatable issue is how to address this deficiency, which is a highly controversial topic. Since Taproot was proposed, 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 in different transactions as long as the input script and amount are the same. This proposal is specifically designed to optimize the Lightning Network and its multiparty versions.
CHECKTEMPLATEVERIFY (CTV) is a proposal that requires coins to be spent only by transactions that match predefined transactions completely. This proposal is designed to extend the functionality of off-chain pre-signed transaction chains by making them completely trustless. OP_VAULT is specifically designed to set a “timeout period” for cold storage solutions so that users can “cancel” extraction from cold storage by sending it to an even colder multisig setup to prevent key leakage.
There are many other proposals, but I think you already understand the point. Over the past few years, each proposal has been aimed at either slightly increasing scalability or improving a single small feature because that was deemed desirable. This is why these discussions have not made progress. No one is satisfied with other proposals because they do not meet the use cases they want to see.
Except for the proposers, no one thinks any proposal is comprehensive enough to be considered a reasonable next step.
That’s the logic behind the “Great Code Recovery.” By pushing for and analyzing a full recovery of the script, as originally designed by Satoshi Nakamoto, we can actually explore the entire functional space we need instead of arguing and fighting over which small feature extension is good enough at the moment.
OP_CAT: Takes two pieces of data from the stack and concatenates them to form one piece of data.
OP_SUBSTR: Takes a length argument (in bytes) and retrieves a segment of data from the stack, removing that length of bytes and placing it back on the stack.
OP_LEFT and OP_RIGHT: Take a length argument and retrieve a segment of data from the stack, removing the specified length of bytes from one side or the other.
OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT, and OP_DOWNSHIFT: Take a data element and perform the corresponding bitwise operation on it.
OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, and OP_MOD: Mathematical operators used for multiplication, division, and modulo operations (returning the remainder of division).
In addition to the opcodes to be recovered listed above, Rusty Russell also proposed three additional opcodes aimed at simplifying the combination of different opcodes:
OP_CTV (or TXHASH/equivalent opcode): Allows fine-grained enforcement of certain parts of a transaction, requiring them to match predefined content completely.
CSFS: Allows verification of signatures not only for the entire transaction but also for certain parts of the script, allowing for certain parts or the use of certain data to be required.
Signature is required to execute the transaction.
OP_TWEAKVERIFY
: The verification is based on Schnorr operations, involving public keys, such as adding or subtracting individual keys from aggregated public keys. This can be used to ensure that when a party unilaterally spends an unused transaction output (UTXO) from a shared output, the funds of all other parties are sent to an aggregated public key that can be cooperatively spent without requiring the signature of the party that left the shared output.
The second layer network is essentially an extension of the Bitcoin base layer, and its functionality is constrained by the base layer. The Lightning Network requires three separate soft forks before it can be implemented: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV), and Segregated Witness (SegWit).
Without a more flexible base layer, it is not possible to build a more flexible second layer network. The only shortcut is to trust third parties, which is very straightforward. I hope that we all desire to remove trust in third parties as much as possible from every aspect of Bitcoin’s scalability interaction.
We need to be able to do things that are currently not possible in order to securely merge two or more people into a single unused transaction output (UTXO) and to be able to execute it on the base layer without trust. The current flexibility of Bitcoin’s scripting language is not sufficient. 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 spends their own UTXO without putting other users’ funds at risk.
At a higher level, here is the functionality we need:
We need to be able to verify specific details about the spending transaction itself on the stack, such as “this portion of the money will flow to this public key of an output”. This allows me to spend my funds using my specific Taproot branch while ensuring that I cannot take anyone else’s funds. The executing 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 by other participants.
Suppose we further develop the concept of a single UTXO with a large number of people who can freely enter and exit. In this case, we need a way to track who has how much money, typically using a Merkle tree and its root. This means that when someone exits, we need to ensure the “record” of who has the right to receive what as part of the change UTXO of other people’s funds. This is essentially introspection for a specific purpose.
We need to ensure that modifications to the aggregated public key can be verified on the stack. In the shared UTXO scheme, our goal is to facilitate the cooperation and efficient flow of funds through an aggregated public key that includes all participants. When someone unilaterally leaves the shared UTXO, we need to remove their individual public key from the aggregated public key. If all possible combinations are not calculated in advance, the only option is to verify whether subtracting a key from the aggregated public key will generate a valid public key composed of the remaining individual public keys.
VAROPS As I mentioned above, the reason for disabling all these opcodes is to address DOS attacks (which cause the network to crash by sending a large number of garbage requests), which can cause nodes that make up the network to crash. There is a way to address this issue, which is to limit the amount of resources any of these opcodes can consume.
When it comes to signature verification, the most expensive part of the Bitcoin scripting language, we already have a solution called the signature operation (sigops) budget. Each use of a signature check opcode consumes a certain “budget,” which is the number of signature operations allowed per block, setting a hard limit on the cost of verifying a block for a transaction.
Taproot changes the way this works by no longer using a single global block limit, but instead having each transaction have its own sigops (signature operations) limit, proportional to the size of the transaction. This is essentially equivalent to the same global limit but easier to understand how many sigops are available for each transaction.
The change in how Taproot handles the sigops (signature operations) limit for each transaction provides a possibility for a generalized approach, which is also a suggestion made by Rusty Russell in terms of varops limit. The idea is to assign a cost to each re-enabled opcode, taking into account the worst-case scenario that each opcode can create in terms of the most expensive computational cost generated during verification. This way, 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 transaction using these opcodes, allowing for convenient reasoning while still accumulating to the implicit global limit for each block.
This will address DOS attacks (which cause the network to crash by sending a large number of garbage requests), as these garbage transactions are also the reason why Satoshi Nakamoto initially disabled all these opcodes.
I understand that many of you may think “this change is too big.” I understand this sentiment, but I think an important aspect to understand as 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 in the fact that we will thoroughly examine a large foundational component package and ask ourselves what functionalities we truly want in terms of features.
This will be a complete shift from the past three years of arguing and debating over minor and narrow changes that only have certain functionalities. It’s like a square where everyone can gather and collectively examine the direction of the future. Perhaps we will eventually restore all these functionalities, or perhaps we will only enable some, because consensus is about agreeing on which functionalities need to be turned on.
Regardless of the final outcome, this can be a transformative change that has a positive impact on the entire conversation about our future direction. We can actually map out and fully understand the situation instead of groping forward when debating which dim path to take next.
This is by no means the path we must take, but I believe it is the best opportunity for us to decide which path to take. It’s time to start cooperating in a practical and effective way again.
Related Reports
Knowledge | Want to understand BRC-20? First, learn about Bitcoin’s “UTXO model.”
Bitcoin transaction volume drops by 99% from its peak, transaction fee below $3, market calms down?
Grasp the Burst》Countdown to the launch of Runes on the Rune platform: Participation, wallet registration, and UTXO splitting comprehensive guide