Understanding CheckTemplateVerify: A dive into the controversial Bitcoin Improvement Protocol
Introduction
One of the most beautiful things about Bitcoin is the fact that it is a piece of technology that belongs to no one and can be improved by anyone. Bitcoin Improvement Proposals (BIPs) are proposals that suggest improvement to Bitcoin (yes, exactly like the name) and these proposals can be made by anyone passionate about contributing to Bitcoin. You can read more about BIPs here.
In this article, we would be exploring BIP 119 which is also called CHECKTEMPLATEVERIFY and how the implementation of this BIP would affect the way people use and spend Bitcoin
What is CHECKTEMPLATEVERIFY
Do you know how every month when you receive your salary you promise that you would dedicate 40% of it to savings and 20% to investment but you end up splurging everything on the latest gadgets? Well, the CHECKTEMPLATEVERIFY (CTV) proposal for Bitcoin seeks to address this.
CTV is a proposal by Jeremy Rubin in May 2019 to improve Bitcoin through a soft fork that allows a user to restrict where they can spend some of their Bitcoin through a setup known as a Covenant. It is important to note that the restriction is not stipulated by the party sending the Bitcoin, rather it is placed by the party receiving the Bitcoin
In Bitcoin, every UTXO or "coin" has a locking and unlocking script. The locking script is the condition placed by the sender of the UTXO that specifies the conditions under which a transaction can be spent. A typical Bitcoin transaction like a Pay to Publick Key (P2PK) or a Pay to Public Key Hash (P2PKH) has the sender using the Recipient's Public key, the hash of the public key or an address generated from the public key (P2SH) as the scriptSig for unlocking a UTXO. Once a user wishes to spend the UTXO, they can create a signature from their Private key which is then verified using the public key associated with that address and the OP_CHECKSIG opcode in the locking script of the output being spent.
CTV introduces extra conditions to the unlocking script.
The way it works is the recipient constructs an address that embeds the extra information about spending the UTXO and sends that to the sender. This extra information can be used by the recipient to restrict where the coins can be sent after the correct signature is provided. This implementation has alot of benefits, especially for security and fraud protection.
For instance, if an attacker get access to your private key and you hold coins that are regulated by CTV, the attackers would not be able to spend your coins because they do not know the extra spending conditions you have placed on your coins.
Differences between CHECKTEMPLATEVERIFY, CHECKMULTISIG AND CHECKTIMELOCK
Aside from CHECKTEMPLATEVERIFY, there are other ways to introduce extra spending conditions to a locking script in Bitcoin.
CHECKTIMELOCK (OP_CHECKTIMELOCKVERIFY) are smart contracts in Bitcoin that restrict the spending of some bitcoins until a specified future time or block height is exceeded. Timelock is typically set by the sender of the Bitcoin.
CHECKMULTISIG on the other hand are smart contracts that require multiple (m-of-n) signatures to access funds stored in a Bitcoin address.
The major differences between the three can be found below
| Feature | CTV | Timelocks | Multisig |
| Purpose | For restricting where coins can be spent after verifying a signature | For specifying when coins can be spent in Bitcoin | For enabling more than 1 signature to approve spending of coins |
| Initiator | CTV is specified by the recipient | Timelocks are constructed by the sender | A multisig address is created by the recipient of the funds |
| Security | Protects funds from being spent by an attacker as the malicious party does not know the extra spending conditions set | Does not fully protect funds from being spent by an attacker who has access to a user's private keys and knows the nLocktime | Protects funds from being stolen/spent by an attacker if any of the signees is hacked. |
CTV use cases
Aside from the additional security that CHECKTEMPLATEVERIFY brings to Bitcoin, there are also a couple of other use cases that it unlocks:
- Vaults: Similar to the way automated savings applications function to transfer some of the money in your bank account to your locked savings account on the app, CTV can also be used to implement a vault such that Bitcoin you receive to a particular address can only be sent to your vault (or cold wallet).
For example, a cold wallet can be set up where one customer support desk can, without further authorization, 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. (source: utxos.org)
Congestion Control: When there is a high demand for blockspace it becomes very expensive to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume payment processor may aggregate all their payments into a single O(1) transaction for purposes of confirmation. Then, sometime later, the payments can be expanded out of that UTXO when the demand for blockspace is decreased (Rubin 2022)
Improvements to the Lightning Network: The maximum number of HTLCs that is allowable in a Lightning channel is currently set at 483. This is to prevent a transaction from being too large which could disrupt the broadcast and confirmation of the transaction to the Bitcoin blockchain. With CTV, less data can be used to create an HTLC, hence allowing for more than 483 HTLCs to be used in a Lightning channel.
Conclusion
Although CHECKTEMPLATEVERIFY has its merits and reasons for being a viable BIP, it is still a draft proposal in Bitcoin. Personally, I love the idea of being able to control the funds I receive to an address at the point of receiving them as it reduces the chances of coins being spent erroneously or fraudulently. However, these use cases can already be achieved using smart contracts like CHECKMULTISIG.
As most opposers of the CTV soft fork would say:
“We don’t add things to Bitcoin just to find out whether we can"
I look forward to seeing more proposals like CTV being suggested by people passionate about Bitcoin.
References
Next-Gen Smart Contracts for Bitcoin: https://utxos.org/uses/scaling/
What is BIP 119 and Why Did it fuel such heated discussions in Bitcoin? https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained
Analyzing BIP119 and the controversy surrounding it:
https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it