Bitcoin – The Soft Fork of Discord

full version at cointribune

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

Bitcoin Soft Fork

It 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:

[By the way, Blockstream founders like Gregory Maxwell, Pieter Wuille, or Adam Back were protagonists of the “Blocksize war.” It is quite respectable that BIPs be endorsed by Blockstream to hope to become reality. Bitcoin Core’s main maintainer Andrew Chow belongs to Blockstream.]

Hop Hop

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.”

Covenants

Currently, 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 often come up in the debate:

OP_CHECKTEMPLATEVERIFY (CTV): The main utility put forward is the possibility for several people to share the same utxo (BIP119 proposed by Jeremy Rubin) in case of excessively high transaction fees. It’s a sCaLing sOluTIon that isn’t really one, among other more or less interesting possibilities.

OP_VAULT: This covenant allows a user to determine when and where the bitcoins can be moved, including in subsequent transactions.

If an employee with access to the private keys tries to steal bitcoins, the company can transfer the funds to a predetermined recovery address before the bitcoins are transferred to an address belonging to the thief.

OP_CAT: This OP_code is even more controversial because it can be “recursive.” That is, it applies not only to the next transaction but also to all subsequent transactions that will spend the bitcoins concerned. Spending conditions can thus be applied recurrently/perpetually.

Does Bitcoin Really Need These OP_codes?

Recursive covenants raise the question of currency uniqueness. A bitcoin whose spending is conditioned is necessarily worth less than a bitcoin whose spending is not conditioned. A 100-euro banknote is worth more than a 100-euro voucher valid in a single store…

Moreover, OP_CAT is supported by Taproot Wizards, a dubious clique of developers led by the intriguing Udi Wertheimer. Their efforts to ruin bitcoin decentralization by popularizing inscriptions (Ordinals, stamps, etc.) should set off red flags…

Finally, the real utility of these OP_codes remains to be demonstrated. Besides exchanges, which companies need OP_Vault? Regarding CTV, what problem are we trying to solve? After 15 years of existence, there are only 16 million utxo containing more than 2600 dollars, knowing that around 150 million utxo can be created each year.

All these proposals have in common that they bet on the fact that bitcoin will become a popular means of payment. We are still far from it. So there’s no rush.

Could these increasingly complex “solutions” be an expression of a certain form of denial? We will have to admit that bitcoin cannot rival Mastercard (high conversion and transaction fees).

Blasphemy or objective analysis? Maybe we shouldn’t expect too much from bitcoin, whose main offer is to be an absolute store of value, not an alternative to the fiat system. Perhaps it is better not to integrate useless gadgets that will introduce new vulnerabilities for no reason. A dozen vulnerabilities were recently unveiled…

If you liked this article, you will appreciate this one on the DoS attack of inscriptions.