Check Template Verify (CTV) and the debate about the next Bitcoin upgrade

With the start of the new year 2024, many users and, above all, developers of the Bitcoin network are asking themselves whether it could be this year again: A soft fork and thus a new upgrade for Bitcoin. The last major change, the Taproot upgrade from 2021, will celebrate its third birthday this year, while six years have now passed since its predecessor, the Segwit upgrade from 2017. The time intervals alone raise the question of when the next big step for the Bitcoin network is due - or whether it is not yet too early.

The debate about the next Bitcoin upgrade is anything but settled. There is no clear favorite among the numerous proposals, nor is there any consensus on their necessity. However, the fundamental need for more functionality and thus also new scaling options for Bitcoin can be found in many voices. We therefore take a closer look at the BIP-119 (Bitcoin Improvement Proposal) with Check Template Verify (CTV), which caused a lot of discussion in the community in 2022 and is now increasingly being advocated, but also critically discussed, on platforms such as 𝕏.

One keyword that is by no means exclusive to Jeremy Rubin's proposal in BIP-119 is covenants. Generally speaking, this is an umbrella term for more complex restrictions that define how a certain amount of Bitcoin may be spent. While this general definition already applies to existing functions today, in the context of Bitcoin, covenants are usually understood to be restrictions that specifically determine "where" Bitcoin may be spent, i.e. that impose conditions on a future transaction. For example, Bitcoin could be sent to an address from which it may only be spent to a predefined other address.

This functionality cannot currently be realized with the technical conditions in the Bitcoin network, more precisely with the Bitcoin script language. This is precisely where various proposals, including Check Template Verify, want to start.

Specifically, BIP-119 proposes a new command (opcode) for the Bitcoin script language: OP_CHECKTEMPLATEVERIFY. This command "introduces a simple covenant that enables a limited number of extremely valuable use cases without incurring significant risk" - according to the proposal's motivation.

This is because a common point of contention around covenants is the risk of permanently and irrevocably tying conditions to a certain amount of Bitcoin. Such "recursive" covenants would make it possible, for example, to never be able to send Bitcoin paid out by a crypto exchange to a predefined "blacklist" of addresses. For many, this is justifiably quite a no-go for the resistance to censorship and the free basic idea of Bitcoin. In general, the specific risks of such powerful covenants have not yet been sufficiently identified.

It is precisely for this reason that covenants with CTV are designed to be quite simple and limited from the outset. A so-called "template" can be defined, i.e. a template of what a future transaction should look like. As the name "Check Template" suggests, the verification of such a future transaction checks whether it corresponds to the predefined template. If not, the verification fails and the transaction is invalid. If it does, the condition of the covenant has been fulfilled and the Bitcoin can be issued. However, the condition of the covenant "expires" and cannot be automatically transferred to any number of subsequent transactions.

On the other hand, one of the advantages of CTV, namely that it is quite specific and limited, has a somewhat negative effect on the actual possibilities. Although some things can be implemented with CTV, some compromises still have to be made compared to more "universal" functions such as OP_CAT.

One of the most prominent use cases are so-called vaults, i.e. special Bitcoin wallets that only allow spending in stages and with a mechanism for emergencies. This is intended to protect your Bitcoin from attackers without having to make too many compromises in terms of user-friendliness. This is an interesting function for both simple Bitcoin users and large asset managers.

Fundamentally, the introduction of covenants also enables so-called "congestion control" transactions, which is also a key motivation for CTV. The basic principle here is that a single transaction (or a single UTXO) can, after sufficient confirmation, assure several users that they can be paid, as this can be verified by the covenant - without the payment having to take place directly. In this way, payments can initially be secured, but only actually made at more favorable times. This basic principle can also be applied to more complex scaling methods such as Ark, whose functionality is basically very similar.

Put simply, there is potential for scaling, also in combination with the Lightning Network through so-called channel factories, in which payment channels can be managed more efficiently using the basic principle just mentioned. There is also some talk of potential improvements with regard to CoinJoin transactions and privacy in general.

The crucial - but still unclear - question remains: The possibilities are all well and good, but why choose Check Template Verify for implementation when there are other suggestions? With OP_CAT, the examples just mentioned could also be implemented, and with a less complex upgrade that potentially even offers more universal functions. On the other hand, it is argued that CTV has no obvious technical disadvantages and that the deliberate restrictions also ensure a low risk. So how should we determine which proposal is the best for the Bitcoin network, or whether such a proposal even exists? This is not an easy question, and there is still plenty of room for discussion for the time being.

The second, equally important, argument is also the fundamental question of whether an upgrade for the Bitcoin network is so urgently needed - at least for the time being. Some see exciting new possibilities that are unavoidable for the scaling of Bitcoin, while others miss concrete implementations or advantages that were provided "out of the box" with Segwit or Taproot. Check Template Verify, but also other approaches for covenants, are initially only building blocks to enable the actual benefits through their development. Since upgrades for the Bitcoin network always initially create more complexity, it can be difficult to justify them as long as no ready-to-use applications are based on them. This is often countered with the argument that there is little incentive to develop functions that may never be used if a corresponding soft fork is not activated. So is this the well-known chicken and egg problem?

Either way, it is important to think about and debate future changes to the Bitcoin network - regardless of which side you are on. The slow and cautious development of Bitcoin should be seen as an advantage rather than a disruptive factor. A change to the rules of Bitcoin in the form of a soft fork is not to be taken lightly and should not be driven by the compulsion to simply "change something", but by real solutions to problems and improvements.