Bitcoin gets a fair amount of stick for “not innovating” fast enough and that these other cryptocurrencies are racing ahead by improving their technology. When you focus only on the technology, you tend to allocate resources to all sorts of ideas and features. Many of which aren’t necessary and offer very little to the network, but the constant need to deploy to maintain the hype forces these projects to keep pushing out updates.
In Bitcoin, however, upgrades are relatively slower, with more reviews and far more methodic. It’s not about pushing updates for update’s sake, as proposing a new soft fork can take time to implement, as we’ve recently seen with the latest taproot signalling and update.
Bitcoin has several developers working as core contributors, and they all have ideas and visions for new updates. Some to improve the bitcoin network while others focus on improved integration for second layer solutions like the lightning network.
Bitcoin improvements are proposals known as BIPs, (Bitcoin Improvement Proposals). Where developers submit their idea for an upgrade, and the community then review these submissions and apply it to test-nets to see how it functions. There are several BIPs currently in progress, and one of them is BIP 119 called OP_CHECKTEMPLATEVERIFY, or simply OP_CTV, an upgrade that has received a lot of attention both positive and negative but is likely to end up added to Bitcoin.
OpCodes have always been around.
There was initially a range of opcodes that could be executed within bitcoin transactions. Still, Satoshi disabled a lot of them early on after it became apparent that the existence of these scripts increased the attack surface of the protocol. Since bitcoin was still in its infancy, Satoshi decided that simplifying bitcoin to reduce the attack surface would be the best option for longevity.
The more code and complex the execution within transactions, the more unknowns and conflicts can arise. This increases the network’s fragility and susceptibility to black swan events. Maintaining the robust nature of bitcoin is a top priority, which is why the proposal of any upgrade receives so much scrutiny. You are placing at risk a near trillion-dollar network and our one shot at achieving sound money.
Who proposed OP_CTV?
Bitcoin Core contributor Jeremy Rubin is the developer behind BIP 119 and explains that in the broader implementation, covenants add risks and have been controversial. 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 focuses on reducing the extent of commands, so it does not risk restricting some coins forever. CTV acts as a more straightforward and safer form of a covenant, which should not progress further to avoid issues like fungibility and censorship resistance.
Jeremy proposes a “simple covenant called a *template* which enables a limited set of highly valuable use cases without significant risk”.
The logic behind CTV is that when constructing a covenant, information about the future transaction should be recorded. This is the condition against which the future transaction is checked. If the transaction that spends those coins does not match the template condition, it will be invalid.
An example would be sending a coin to the mempool but specifying the sat per byte cost you’re willing to pay so the transaction is only picked up and confirmed by a miner who is willing to accept that fee. The coin can remain in the mempool until the condition is met.
Simply put, we record, as a condition, that a specific transaction (not any other) must be carried out to spend some coins.
What are the use cases for OP_CTV?
There are a couple of use cases for CTV namely for congestion control and the creation of wallet vaults.
Congestion controlled transactions
Block space on the bitcoin network is a finite resource, and as demand increases for bitcoin, so will the cost to get into the next block. We’ve already seen how bidding for block space can increase how bad network congestion can be during bitcoins 2017 blow-off top, hitting $20 000, with fees sitting around $50 a transaction.
When there is a high demand for block space, it becomes costly to make transactions. For exchanges and bitcoin companies who constantly have to process large volume payments, they may aggregate all their payments into a single O(1) transaction commitment for purposes of confirmation using CHECKTEMPLATEVERIFY.
Then, sometime later, the payments can be expanded out of that UTXO when the demand for block space has decreased. These payments can be structured in a tree-like fashion to reduce individual redemption costs.
What this means is that the exchange would commit one transaction that will wait for the network to meet its free requirements before executing—making it more efficient, using less block space but servicing multiple users with different addresses.
Wallet vaults
There are two variations on wallet vaults built using CTV. In the first instance, wallet vaults are a helpful tool when more significant security is required for cold storage solutions, providing default transactional paths that move funds from one’s cold storage to a hot wallet.
In the example of an exchange, they can set up a cold wallet for a customer support desk, which can move funds without further authorisation. They can move a portion of the funds (using multiple pre-set amounts) into a lukewarm wallet operated by an isolated support desk.
The support desk can then issue some funds to a hot wallet and send the remainder back to cold storage with a similar withdrawal mechanism in place. This is all possible without CHECKTEMPLATEVERIFY, but CHECKTEMPLATEVERIFY eliminates the need for coordination and online signers, as well as reducing the ability for a support desk to improperly move funds. Furthermore, all such designs can be combined with relative time locks to allow compliance and risk desks to intervene.
As for the individual, you could use Sapio, a smart contract programming language. In this design, the user commits to a single UTXO that contains a program for an annuity of withdrawals from cold storage to a hot wallet. At any time, the remaining balance for the annuity can be cancelled and funds locked entirely in cold storage. The withdrawals to the hot wallet can be ‘cancelled’ before the maturity date to ensure the action was authorised. These vaults enormously benefit from non-interactivity because the withdrawal program can be set up with cold keys that are permanently offline, except in an emergency.
How CTV affects the lightning network?
When it comes to second layers, CHECKTEMPLATEVERIFY will help the Lightning Network by enabling better Channel Factories for batched channel opens, creating non-interactive channels and increasing the number of overall channel routes.
How CTV affects coinjoins?
The introduction of OP_CTV and the resulting vaults offer better security for transactions and cheaper coinjoins, encouraging users to use the service more and break tracking on coins to improve privacy for more bitcoin.
When CTV?
The proposal has been making the rounds since 2019, with many developers contributing to the project. Questions on its limitations have been discussed online and how it could affect other upgrades like Eltoo and ANYPREVOUT. As far online talks go, it seems to be more positive than negative, with the obvious benefits for various stakeholders, such as individuals, exchanges and bitcoin-based companies.
While we cannot say if or when this proposal could be merged into bitcoin, it does seem like it’s edging closer.
If you want a more technical understanding or want the latest updates on CTV, check out GitHub.
