written by @veriphibtc
The Backwards Compatibility Principle and How Bitcoin Evolves
The Bitcoin protocol began on the basis of numerous rules to which voluntary participants could agree to, in order to function as a standalone network. This set of rules was embedded in the code. It is only when one decides to run their own full Bitcoin node that they can verify themselves that all Bitcoin users are effectively respecting these rules.
As Bitcoin has grown during the past decade, it has become evident that it must evolve continuously for bug-fixing purposes, to increase its transactional throughput, and to implement smart-contract capabilities. There has been a lot of debate regarding how these changes will be brought to the protocol, either through hard-forks or soft-forks. Hard-forks implicate a change in one of the original protocol rules, meaning that a hard-forked Bitcoin software version would no longer be compatible with prior versions.
Evolving the Bitcoin protocol through hard-forks means splitting the network of nodes each time a new upgrade is implemented, making it difficult to maintain the integrity and decentralization of the network. On the other hand, soft-forks are opt-in, allowing users to have the choice to adopt or not. Users deciding to not adhere to the latest soft-fork protocol changes can still remain active and participate within the network. This is known as the backward compatibility principle.
One of the most heated debates about how Bitcoin should evolve came during the blocksize wars of 2017. Some of the highest-profile market participants, such as exchanges and miners, wanted to increase the block size (only possible through a hard-fork). According to them, Bitcoin needed to increase its transactional capacity directly through its first layer as opposed to the advocates who believed base layer optimizations and subsequent protocol layers, such as the Lightning network. The problem with the tactic of changing an initial rule of the protocol is that it sets a precedent of regular protocol changes and the denaturation of Bitcoin.
In the end, it's the users of Bitcoin that won the battle by signaling through their bitcoin full nodes their support for Segwit. Short for Segregated Witness, this soft fork protocol upgrade was proposed to increase Bitcoin scalability instead of increasing the block size. Segwit efficiently leverages the existing code of Bitcoin without disrupting the network because it’s an opt-in measure. It consists of separating the witness part of a Bitcoin transaction and attributing a lower rate of weight to it than the non-witness part. This optimizes space in a singular Bitcoin block, permitting more transactional throughput. Overall, it also benefits users on an individual level since transaction fees are paid according to the amount of data used in a transaction. In fact, if all users and market participants were to use since its inception, they would have saved over $300 million USD.
Developing Bitcoin is extremely difficult, as developers have to deal with pre-existing rules and only bring new protocol updates according to the backwards compatibility principle. However, this difficulty ensures that only widely accepted and reviewed code gets to be included in the most prominently used Bitcoin client: Bitcoin Core. Bitcoin developers are known to have strict standards in that regard, as the updates are infrequent and heavily scrutinized. We have proof with Segwit that some changes are not only positive on an individual user’s level, but for the Bitcoin network as a whole.
Let’s explore a new upgrade idea that came up recently, to be reviewed by the wider Bitcoin community and eventually included in the Bitcoin core client: BIP-119.
What is BIP-119?
For those who don’t know, a BIP is an acronym for Bitcoin Improvement Proposal. This is the standard method that a Bitcoin developer must follow if he wants to propose an improvement idea to be included by the code maintainers of Bitcoin.
BIP-119 was published by Jeremy Rubin on the 1st of June. It proposes a new opcode called OP_CHECKTEMPLATEVERIFY.
Opcodes are short for “operation codes”, which are the operations you can do with a pubkey script or signature script permitted by the Bitcoin script language.
Jeremy wanted to make it simpler and safer to develop smart contracts at the protocol layer of Bitcoin. Currently, there are numerous so-called covenants, which are restrictions that a Bitcoin sender can apply to a UTXO so it only gets spent if certain pre-established requirements are respected. One of these covenants is locktime, which gives users the ability to specify how many blocks before a certain UTXO can be spent. It can be used in various uses-cases like higher operational security, as it is impossible to spend an UTXO that is time-locked.
The new proposed opcode renders all existing covenants into a singular template, decreasing security vulnerabilities that could be exploited if they were to be used separately. When constructing a transaction with that opcode, it is possible to verify that a certain UTXO was conditioned to result in the set of a new UTXO by matching its resulting hash to the preimage of the transaction. You can subsequently link multiple transactions of that type together with conditional rules in a tree-like manner.
What are some of the applications and uses-cases of BIP-119?
One really useful use-case of BIP-119 is a highly ordered and efficient way to spend a certain UTXO or set of UTXO’s when there are multiple recipients involved. It is particularly suitable for users such as exchanges, who are obligated to constantly make payments regardless of if transaction fees are high or not. With the new opcode it would be possible to batch an enormous amount of transactions into one, while the individual recipients would receive their coins according to a set of specified rules. So for example, if at a certain moment fees are really high, an exchange could send an OP_CHECKTEMPLATEVERIFY transaction aggregating all the payments it has to do, but conditioning them to be realized only when transaction fees go lower.
Another great advantage of this new opcode is the expanded logic and capabilities of covenants from an operational security perspective. As Bitcoin continues to grow and its price increases, more companies are offering products and services to properly store and transact the Bitcoin of their clients. Previously, these companies had to deal with the problem of coordinating with other online signers. With the ability to embed pre-existing spending conditions in a transaction, this wouldn’t be an issue anymore.
Beyond BIP-119 modifying the Bitcoin protocol, it also helps the expansion and uses of the Lightning Network. Each individual recipient UTXO in an OP_CHECKTEMPLATEVERIFY transaction can indeed open up a new Lightning channel. This renders the task of creating channels less cumbersome and more efficient.
Want to learn more and help?
Bitcoin developers are constantly working to make it easier and more secure to use Bitcoin in our everyday lives. It is largely thanks to these efforts that Bitcoin continues to thrive today. You can contribute to this pool of work as well!
The amount of complex work already done on BIP 119 is enormous. If you want to learn more or contribute to its testing and implementation, check out this website by Jeremy Rubin: https://utxos.org/.
If you have any feedback on this or any other topic, please feel free to reach out to us at any time at firstname.lastname@example.org or @BTSEcom on Twitter. We always love to hear from our amazing BTSE community.