Bitcoin’s original design included a scripting language that was fully developed to support and encompass any future safe uses cases users might come up with. Satoshi, before his disappearance said:
“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 possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.” – Satoshi, June 17 2010.
This was done to allow users to compose in a way that is easy for them. own Types of transactions, as per their own discretion. I.e. Let users experiment with their programming. own money.
Satoshi, before he vanished, ripped 15 opcodes out, disabled them completely, and added a limit on how large a data piece could be modified in the scripting engine (520 bytes). It was because Satoshi screwed-up and had left open many ways in which scripts that were complex could be used for a Denial of Service attack against the whole network.
The opcodes were removed not because Satoshi felt the functionality to be dangerous or that people should no longer be able build things with them. They have been taken out (at least, it appears) due to the potential risk they pose to the entire network if they are used without any resource restrictions to reduce the worst-case validation costs they can impose.
Then, you can get in touch with us. upgrade Bitcoin has been streamlined since Satoshi’s death, corrected other, less severe flaws, and extended the functionality of the subset script that was left.
Great Script Restoration
Rusty Russell presented a radical idea at Bitcoin++ Austin, Texas in early May. He basically pitched the idea turning back on most of the opcodes Satoshi had disabled the system in 2010, before disappearing.
Since Taproot was activated in the year 2021, development has been a bit aimless. Bitcoin, as we all know, is not large enough to service a significant portion of world population.
It’s not even a question of debate for anyone who has a technical understanding Bitcoin. The debate is about how we can address this problem. Since Taproot was released, there have been many proposals that are very specific and only target a few use cases.
Anyprevout (APO) is a proposal that allows the signature to be reused on multiple transactions, as long the scripts and amounts of input are identical. It was specifically designed to optimize Lightning as well as multiparty versions. CHECKTEMPLATEVERIFY was created to make pre-signed chains more functional by ensuring that coins could only be used by transactions matching a specific predefined transaction. The OP_VAULT is designed to allow a “timeout period” For cold storage plans, so that an user can “cancel” If their keys are compromised, they can withdraw them from the cold storage and send them to a multisig even more cold setup.
You may have heard of other ideas, but you probably get the idea. Each of the proposed solutions over the past few years has been designed either to give a slight increase in scaling or to improve one narrow feature deemed desirable. It is my opinion that this is the best solution. source This is why these conversations aren’t going anywhere. Everyone is unhappy with other proposals, because they do not cater to their desired use case.
The proposal is not comprehensive enough to make anyone think that the original proposer is right. next You can move on.
The Great Script Restoration is based on this logic. The Great Script Restoration is based on the logic that Satoshi originally designed.
Opcodes
- OP_CATTwo data pieces are added together in a stack.
- OP_SUBSTRTakes the length argument, in bytes. Grabs and puts back a data piece from the stack.
- OP_LEFT & OP_RIGHTDeletes bytes according to the size of an argument.
- OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFTTakes an element of data from the stack, and executes the appropriate bit operation It’s a good idea.
- OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MODMultiplication, Division, and Modulo Operations (Returning remainders of division).
Above are a few of the opcodes that will be restored. Rusty has also proposed three additional opcodes that will simplify the creation of the different codes.
- OP_CTV (OR TXHASHIt is a tool that allows for granular control, requiring specific parts of the transaction to match exactly what was defined in advance.
- CSFSThis allows you to verify signatures using arbitrary data instead of just the transaction. It allows for parts of scripts or the data that they use to be required to be verified before being executed.
- OP_TWEAKVERIFYVerifies Schnorr operations that involve public keys. For example, adding or removing individual keys from the aggregate public key. The function can be utilized to guarantee that, in the case of a party unilaterally leaving a shared UTXO without warning or consent from others, the funds sent by everyone else are directed to centralized public keys that do not require signatures to enable cooperative spending.
Why we want to do this
Layer 2s They are, by nature, constrained by the limitations of the Bitcoin base layer. It took three softforks to implement Lightning, CHECKLOCKTIMEVERIFY CHECKSEQUENCEVERIFY CSV and CHECKLOCKTIMEVERIFY CLTV.
It is impossible to build Layer 2s that are more flexible without also having a base layer with more flexibility. There is no other way to get around this than by using trusted third-parties. It is something we should all strive to eradicate from Bitcoin interactions at large scale.
Bitcoin script simply isn’t able to handle the complexity of a UTXO that involves more than 2 people. The most fundamental level is that we require covenants. Scripts must be able to enforce more granular information about the transactions executing them in order to guarantee things such as a user exiting a UTXO safely on their own. own Does not risk the funds of other users.
This is what we want from a higher perspective:
IntrospectionIt is important to have the ability to inspect details of a transaction on the stack itself, including “this amount of money goes to this public key in some output.” This allows me to make a withdrawal by myself from a Taproot branch that I have chosen. ownWhile ensuring I can’t take money from anyone else, the script executes to ensure consensus that everyone owns their correct amount. By consensus, if the user leaves the script will send the amount that they own to the address created by the users public keys.
Carry Forward DataImagine we build a single UTXO containing a huge number of people, where they can all come and go at their leisure. We need to be able to keep track of who owns how much cash, and this is usually done with the merkle trees. We need to know who has how much money when they leave. “record” The change UTXO is the money of others. It is basically a special use of introspection.
Public Key ModificationStack verification is required to verify that changes to the aggregate public key can be made. The ultimate goal of UTXO schemes that involve sharing is the creation of an aggregate public key for all participants. This will allow for a faster and more effective movement. We need to subtract the individual keys from an aggregate key whenever someone unilaterally leaves a UTXO shared. It is impossible to precompute all the combinations, so the only solution would be to confirm that subtracting a single key from the total creates an individual key.
Varops: How to make them safe
As I stated above, these opcodes are disabled in order to reduce the risks of denial of services attacks. These could crash network nodes. This can be solved by restricting the resources that these opcodes use.
There is already a solution for the signature verification. That’s because it’s one of the most costly parts in verifying Bitcoin scripts. This budget is called the “sigops” budget. Each use of a signature check opcode consumes a certain ‘budget’ of allowed signature operations per block. The cost of a transaction to verify a block is therefore limited.
Taproot changed the way that this worked. Instead of using one global block limit for all transactions, Taproot now uses a transaction-specific blocklimit. own Limit of sigops proportional to transaction size It is the same limit globally, but it makes it much easier to calculate how many signatures are available for each transaction.
Rusty’s proposal to use a varops limitation is a generalization of the way Taproot manages sigops limitations relative to transactions. It is proposed to allocate a cost to each reactivated code to account for the worst-case scenario, which would be the most expensive computational cost to validate. Each opcode would have the highest computational cost. Each opcode would then have their own own “sigops” It would be a kind of limit to restrict how many resources the system could use for verification. This would depend on how big the transactions are, in order to keep it simple and maintain the ability to reason about the issue, yet still come up with an implicit global limitation per block.
Satoshi disabled all the opcodes to avoid the risks of denial of services.
Forward Momentum
You’re probably thinking about it. “that is way too big of a change.” Although I am able to empathize, I believe that this proposal as an understanding of the project has a very important element. You don’t have do everything. This proposal’s value is not necessarily turning everything back on, but rather that it would allow us to look at an entire set of primitives in detail and ask ourselves what functionality we want.
This would mean a total reversal of the last three years, when we argued and bickered over small changes that helped only certain functions. The tent is a way to bring people together and assess what to do next. We may decide to turn everything back on. Or we might just activate a few items because that’s what everyone feels is necessary.
It can change the conversation about where to go next, regardless of the outcome. Instead of bumbling about arguing what obscure and dimly lit route to take, we can map it out. next.
We don’t have to take this path. But I believe it will be our best chance at choosing the right one. We need to work together again in a constructive way.
Here is the first video interview in a long series with Bitcoin++ developers who discuss the proposed script restoration. Let’s start with Rusty.
“This article is not financial advice.”
“Always do your own research before making any type of investment.”
“ItsDailyCrypto is not responsible for any activities you perform outside ItsDailyCrypto.”
Source: bitcoinmagazine.com