Bitcoin Soft Fork: Does the Currency Really Need These New OP_Codes?

Some developers are pushing again for a soft fork that has much less consensus than previous ones. It is not easy to alter the bitcoin code.

Some developers are pushing again for a soft fork that has much less consensus than previous ones.

Bitcoin Soft ForkIt is not easy to alter the bitcoin code. We are incentivized to never modify the part of the code corresponding to the 21 million limit.

Some evolutions are nevertheless necessary, others much less so. Unfortunately, there will always be developers who want to bring their bad grain of salt.

Code evolutions are proposed via “Pull Requests.” Most are minor, but some are major. They then become BIPs (Bitcoin Improvement Proposals) which are sometimes “soft forks.”

As a reminder, a hard fork is an evolution of the code incompatible with the old one. The typical example is BCH (Bitcoin Cash). BTC network nodes do not validate BCH blocks because they can exceed the 1 MB limit per block. Such a change triggers a hard fork.

In the case of a soft fork, the two codes coexist on the same blockchain. This is called backward compatibility. For example, we could change the block size to 0.3 MB. This is less than the 1 MB limit and thus backward compatible with the original protocol.

The latest soft forks were SegWit (2016) and Taproot (2021). Some developers are currently pushing for a new fork to allow the creation of “covenants” by adding new OP_codes.

Blockstream Research recently published a fairly detailed summary on the topic:

It is essential to understand the mechanics of bitcoin transactions to understand what covenants are. The magic happens thanks to a computer execution language called “script.” It is a very simple language with a limited number of instructions.

These instructions are called OP_codes. See them as little digital gears that get going when a transaction is validated.

Specifically, making a bitcoin transaction means creating an “utxo” from one (or more) other “utxo” which is destroyed in the process. A utxo is a piece of code (a script) that mathematically links a quantity of bitcoins to a bitcoin address (a public key).

In essence, making a transaction means changing the public key (the bitcoin address) to which the amount of bitcoins is linked.

During a transaction, the star OP_code is OP_CHECKSIG. This checks that the signature matches the public key of the spent utxo. If everything is in order, a new utxo containing the receiver’s public key is created.

Overall, Bitcoin Script is a rather simple “stacked based” programming language that limits the field of possibilities.

Blockstream writes about this:

“As things currently stand, it is not possible to pre-configure how bitcoins from a utxo can be spent or the speed at which they can be spent. The only solution is to tinker using PSBTs (partially signed bitcoin transactions) which cannot properly include transaction fees, among other limitations.”

“The simplicity of the Script programming language, although it is at the heart of Bitcoin’s security model, introduces significant limitations in its ability to support the most elementary smart contracts.”

More Arithmetic in the Stack“Stack based” means that the data needed for transaction mechanics is placed in a “stack” where logical operations are performed.

Example of a transaction verification mechanism:

The OP_code OP_DUP will DUPlicate the public key of a utxo and place it in the stack.

The OP_code OP_HASH will hash this key (which transforms it into an address to which the bitcoins were mathematically linked in the utxo)

OP_EQUALVERIFY verifies that the resulting hash indeed belongs to the utxo in question.

OP_CHECKSIG verifies that the provided signature matches the public key of the utxo.

Bitcoin Script has just under 100 non-trivial OP_codes. However, it is not possible to multiply, divide, or concatenate (combine) data in the stack.

Satoshi disabled several OP_codes in 2010 (OP_OR, OP_MUL [multiply], OP_DIV [divide], and OP_CAT [concatenate]). These OP_codes were removed because their original implementations had exploitable vulnerabilities that could compromise network security.

Their absence, however, makes it difficult to create certain exotic spending conditions (smart contracts). Notably, the inability to define spending conditions in the utxo based on transaction data.

Blockstream explains:

“If the script had the ability to interpret more details inside transaction data, we could build much more robust contracts that allow for specific spending conditions.”

CovenantsCurrently, the only “smart contract” possible with bitcoin is simply the classic act of locking and unlocking bitcoins linked to a public key. Making a transaction, in essence.

Covenants aim to create a new type of utxo allowing the sender of a transaction to impose certain conditions on how the recipient can spend the bitcoins subsequently.

Here are two OP_codes grouped under the term “covenants” with limited capabilities that

The above is the detailed content of Bitcoin Soft Fork: Does the Currency Really Need These New OP_Codes?. For more information, please follow other related articles on the PHP Chinese website!