In the journey to improve Bitcoin there are many paths to follow. Every developer has a vision of what Bitcoin should look like and patiently works towards it. But Bitcoin is very difficult to change, and this is not a bad thing. On the contrary, its greatest value comes from its immutability.
Consensus has recently been reached to activate the Taproot upgrade, a proposal that has been in the works for years. From this, discussion on new proposals has resumed in the more technical community.
Bitcoin improvements are proposed in BIPs, (Bitcoin Improvement Proposals). We recently discussed BIP 118, and I’ll explain what BIP 119 is. This proposal, also called OP_CHECKTEMPLATEVERIFY, or simply OP_CTV, has received a lot of attention and is likely to end up in Bitcoin.
Check Template Verify
The proposal consists of a new Opcode, an operator for the Bitcoin language. In the Bitcoin Script there are some operators that are useless, the OP_NOP. These were introduced by Satoshi to allow updates in the future and so far 3 have been used.
With this trader you can build “covenants”, a very peculiar type of transactions. In Bitcoin, coins are locked in UTXOs, a set of rules about what is needed to unlock and spend them.
For example, a UTXO may require a person to have a private key to spend its coins. This is the most common case, where a person proves by means of a digital signature the possession of that private key. Therefore, if you don’t have your private keys, you don’t have your Bitcoin.
The conditions of what is needed to spend some coins can be more complex, but they do not enter into how to spend them. With covenants, the condition of how they should be spent can be added.
In other words, without OP_CTV a user can spend coins in any way when unlocking them. With OP_CTV an additional condition is how they are to be spent. Covenants restrict how coins will be spent, and can open doors to really complex smart contracts.
But, as Jeremy Rubin (the developer behind BIP 119) explains, covenants add risks and have been controversial as a result. One of those risks is that some coins may be subject to conditions in perpetuity, worsening Bitcoin’s fungibility. That is, not all coins are worth the same because there are some with restrictions on their use. Jeremy’s implementation does not have the risk of restricting some coins forever, and it is simpler and safer than other forms of covenant.
The logic is that when constructing a covenant, information about the future transaction should be recorded. This is the template against which the future transaction is checked. If the transaction that spends those coins does not match the template, then it will be invalid.
In this simple way we record, as a condition, that a specific transaction (not any other) must be carried out in order to spend some coins. Let’s see some uses of this.
What are the possible uses of OP_CTV?
An implementation of BIP 119 in Bitcoin, would open the doors for new uses and advantages. Some of them could be:
Combating network congestion
One high-value use for Bitcoin is as a tool to reduce network congestion. We already know that when there is a lot of demand for transactions (usually in a bull market) transactions accumulate on hold (in the mempool). For market effects, transactions must pay more commission to be included at that time.
One way to combat this is with OP_CTV. We can send coins from many users in a group to a UTXO where the transactions needed to spend it are recorded.
Let’s imagine that an exchange wants to send money to different users, but there is a lot of network congestion at that moment. What it does is to send the coins to a single UTXO (a single address) using the OP_CTV. When the congestion is reduced, that UTXO can be spent in the preset way, according to the template (sending to all users).
This can be thought of as a cheaper intermediate transaction, which ends up in the final transaction when commissions are already low. The savings in commissions and congestion can be very significant according to Jeremy Rubin’s simulations.
At Lightning Network
OP_CTV can also be used for Lightning Network, Bitcoin’s scalability solution that allows thousands of transactions per second with low fees. Lightning Network is a set of constructs called payment channels, which allow two users to maintain independent balances to the blockchain.
One use is channel factories, which allow many participants to use a single Lightning channel (currently only two participants). This allows Lightning to scale much more, enabling millions of people to use it. Channel factories would also be possible with BIP 118, although in this form they have different features.
In addition, these covenants can be used to create non interactive channels that allow for more convenient and independent channel management and, thanks to the congestion tool, improve network efficiency.
Vaults and Coinjoins
Other uses of OP_CTV are vaults for better security and cheaper coinjoins (a privacy technique in Bitcoin).
Sapio, a language based on OP_CTV
Jeremy Rubin has also developed a language for Bitcoin programming called Sapio. Sapio uses BIP 119 to create smart contracts in Bitcoin and has the potential to challenge the “Bitcoin can’t have complex smart contracts” statement.
Sapio is currently used in Bitcoin by means of an oracle that allows to emulate OP_CTV. Should this proposal move forward and end up in Bitcoin, Sapio could be used to its full potential and without trust (without relying on third parties like oracles).
BIP 119 could be a key enabler of more applications and innovation on Bitcoin. And thanks to Sapio, its potential would be much more accessible to programmers who want to build on Bitcoin.
