Abstract: We examine and explain a proposed softfork upgrade to Bitcoin, OP_CTV (Check Template Verify). This feature would enable users to commit to spending a Bitcoin output, only under certain restricted conditions. The main proponent of this upgrade, Jeremy Rubin, in a bold move, recently announced the imminent release of a new client with OP_CTV activation parameters. We discuss the proposed softfork activation mechanisms with Jeremy, challenging him on some of the most controversial aspects of his proposal.
Introduction to OP_CTV
OP_CTV (Check Template Verify) allows a user to create a Bitcoin address that is associated with a commitment hash of some components in a potential future transaction, most notably the commiting to the transaction outputs. This commitment hash is typically revealed on redemption of the funds in the witness field, instead of the digital signature and revealing the hash authorises the spend. Thereby, if any coins are sent to this address, the funds can only be spent under certain conditions, the conditions that have already been committed to by the hash. This is sometimes called a covenant.
This upgrade is relatively simple and has the potential to add several features to Bitcoin with minimal risks, which is why this type of idea has many proponents. OP_CTV requires a new OP code (Or more precisely, tighter conditions associated with an existing unused OP code put there by Satoshi in 2010) and is therefore a softfork upgrade to the Bitcoin protocol. The OP code in question is OP_NOP4.
Testnet usage and examples
An OP_CTV testnet has already been launched. The below example transaction makes use of OP_CTV. The transaction before this can be thought of as the commitment transaction. 15.00003992 BTC (On the testnet) were sent to address tb1qmce….vs4627. The funds could only be redeemed using the OP_CTV script in the witness field. This contains the OP code “OP_NOP4” and the following commitment hash:
a9a39b05196b80c94936432f6e59242e504a9c394e083da34adf6aaef5b29d2a
Source: https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e
The hash of the transaction outputs and some other transaction data must match this value. This matching is the authorisation for the transaction and therefore no digital signature or private key is required to authorise the spend. If the hash does not match, the transaction is invalid according to the new proposed softfork rules.
The below table illustrates which components of Bitcoin transactions can change and which components cannot change due to the commitment hash.
Transaction data committed to by the hash | Transaction data that can change |
|
|
Congestion control
The most cited use case of OP_CTV and one we will focus on first is congestion control. This is perhaps not the most useful feature of OP_CTV, but it is the one most helpful in explaining how OP_CTV works, in our view. Consider the scenario where a cryptocurrency exchange wants to conduct a batched withdrawal to many clients (one input and many outputs). However, fee market conditions are tight and the exchange wants to avoid high fees. Therefore the exchange uses OP_CTV, by creating two transactions:
- Sending the funds to one output in the commitment transaction, and
- The next transaction, which spends those coins, in a multiple output transaction
Transaction 1 is small in size and therefore confirms quickly for a low fee. Transaction 2 is broadcast into the memory pool (typically after transaction 1 has already been confirmed), such that the exchange’s clients can potentially see the transaction and the outputs going to them. Since the commitment transaction is confirmed, the exchange’s clients know they are guaranteed to get the funds, or at least that the exchange can never double spend them. At some point later on, when fees market conditions have loosened, transaction 2 is confirmed and everyone gets their money.
This OP_CTV system is said to be superior to the RBF and CPFP alternatives for the following reasons:
- One can construct a tree of these OP_CTV transactions, such that all the hashes hash back to the original commitment hash in a merkle tree. The sub branches of these trees can have different fee rates. For example higher fees for higher priority customers. On the other hand, with a batch RBF transaction, all outputs must have the same feerate, which is considered as a disadvantage of regular batching
- Before the original commitment transaction is confirmed, the exchange can keep adding new outputs to the structure and replacing the original transaction via RBF. If one is not using OP_CTV, replacing the batched transaction like this is unfeasible because the minimum fee increase is applied across all the outputs and therefore it becomes prohibitively expensive
Despite these advantages, in our view, congestion control is not particularly compelling, for the following reasons:
- Current fee market conditions are loose
- It may be unlikely that fee market conditions vary sufficiently within the timeframe that this setup is relevant, for it to be useful
- Many exchange clients want fast access to funds, rather than knowing the exchange is committed to paying them
- Exchanges may not care enough about this issue to adopt such a complicated solution
- We already have RBF and CPFP
- As far as we can tell, OP_CTV transactions would be considered by existing clients as a non-standard. Therefore, non-upgraded wallets may not see the incoming transaction until it confirms, thereby the benefits of this proposed system are lost until people upgrade their wallets. This seems like a significant potential flaw
- This introduces a new class of incoming transactions, resulting in three classes: i. Confirmed, ii. In the memory pool and iii. Committed to by OP_CTV. This new transaction status adds complexity for users, who are unlikely to understand it
Despite our scepticism about the congestion control example above, OP_CTV is a simple upgrade and has the potential to add a lot of features and flexibility, with minimal risk. It could add features that we do not even know about yet. Congestion control should just be thought of as an illustrative feature. Therefore one can see how the proposed upgrade is popular in the technical community.
Vaults
Perhaps a more compelling use case for OP_CTV, with more immediate applications, is vaults. With a vault, one wants Bitcoin inside the vault to only be sent to certain addresses under certain conditions. This can be achieved today by pre-signing transactions and then destroying the private keys. However, it may be challenging to demonstrate that the private key was destroyed. Using OP_CTV, the restrictions on what can be done with the funds in the vault can be enforced by Bitcoin’s consensus rules themselves, not the messy storage of pre-signed transactions. Without an OP_CTV type upgrade, it is difficult to see how to achieve this kind of feature in Bitcoin.
Perhaps James O’Beirne’s write up on this potential use case is the most comprehensive and interesting.
Softfork shenanigans
On 17th April 2022, the most significant proponent of OP_CTV, former BitMEX grantee Jeremy Rubin, proposed softfork activation parameters and plans to release an activation client in a blog post. The blog implies software builds for the activation client will be released on or before Sunday 24 April 2022. This controversial move by Jeremy set off a series of debates and comments in the Bitcoin developer mailing list. As a result of this, we interviewed Jeremy and asked him some challenging questions about OP_CTV activation.
Softfork activation Q&A with Jeremy Rubin
The signal period starts on 5th May 2022, only two weeks after you released the proposed activation timeline. Why not give at least a few months between the announcement of the proposed activation parameters and the start of the activation window?
This is actually not entirely true. I announced a similar timeline in December 2021. This was discussed in the January 11th CTV Meeting as well, where there was some support for the spring timeline. In the follow up to that meeting, on January 13th, where there was preference expressed for not merging into Core, and also a pocket-refusal from any maintainer to answer any questions about what to do.
One of the core issues with delaying for a few months is that – it is my opinion that – bitcoin has ‘viable release windows’ for soft forks that point to spring/fall as the only real windows, because we want to avoid signalling or activation during Thanksgiving, Christmas, New Years, Chinese New Years, Valentines Day (jk we’re all foreveralone nerds if you’re reading this post), and Tax Days (stupidly, USA April 15th, China March 31st…) because during this period, people may not be able to dedicate their full attention to a signalling or activation process. This points to doing activations during May through early November, and if we want to stick with a speedy-trial type setup, the signalling must be earlier and the activation later. Therefore, if the Bitcoin network has a preference for Speedy Trial and CTV this year, then the choice of parameters would probably overlap with what I picked pretty closely, and I don’t think people care about the actual numbers for any numerology purposes. However, if we wanted to abandon Speedy Trial in this case (which might be ok?), we could keep the min active height parameter in November and start signalling in e.g. August 1st, and I think it would still be OK, just different from Taproot.
By the way, Taproot’s release parameters were set, if I recall, before the actual release was made.
April 24th, 2021 was the start, and v0.21.1 was released on April 29th. The activation parameters themselves were proposed (as a PR to the code and BIP) on April 13th/14th, which was only 10 days before signalling start.
Might it be a good idea to try and get the code for OP_CTV into Bitcoin Core first, without activation, and once that is done work on the activation methodology (either in Core or other clients)? Is that how Taproot and SegWit was done? Why is it different this time?
Maintainers have not really given me guidance on what the acceptance criteria is or should be, so short of having real clarity on that, my read is that the preference is for consensus changes to be proposed outside of Core going forward.
Do you think some people oppose OP_CTV activation because as it’s author and main proponent, you are relatively new as a developer, compared to those who proposed the previous generation of softforks? (Now developers who are mostly inactive) Perhaps some people feel it represents a changing of the guard, which is difficult for some Bitcoiners to handle?
Someone told me the other day they talked to someone to explain CTV to them, and this is someone I would know for sure and was someone ‘relevant’, that they hadn’t looked at it because they don’t like me.
Nor am I ‘new’ to Bitcoin – I’ve been studying Bitcoin since 2011, and started doing Core Development in around 2015. So the question is, relative to what? Who are the really active contributors who spend time thinking about things like this?
If you saw CTV proposed, which developers would you let your guard down for? Should you have a lower standard based on reputation?
What is the responsibility of the old-guard, if retiring or otherwise inactive, to pass the baton?
What happens when our current technologists do not have a firm enough grasp on the technology to reproduce it?
I think if we don’t grapple with these questions, and improve our engineering capacity, the Bitcoin network may see the fruits of ossification, but the fruit may be a poison apple. While we do work to make Bitcoin more and more robust, the ground truth – outside the narrative – is that Bitcoin is very far from perfect. And when the ‘people who built it’ retire, if the next generation doesn’t possess the same skills, then Bitcoin becomes something we don’t verify, it’s just something we trust…
Conclusion
As far as we can tell, most people seem to support OP_CTV or some technology like it, due to the reasonably simple implementation and very minimal changes to consensus code. However, there are some critics and they seem to fall into the following overlapping categories:
- People who feel the upgrade is not urgent, due to limited demand or limited use cases,
- People who think a superior alternative covenant solution may emerge or should be adopted
Whatever, one’s views on OP_CTV itelsef, the activation system and timeline is bound to be extremely controversial and it looks unlikely that the technical community will reach consensus on this, at least in the next 6 months or so.
For instance, Bitcoin developer Matt Corallo explained his strong opposition to Jeremy’s stance in the Bitcoin mailing list on 21 April 2022:
Given there are still various proposals for covenants floating around and we’re still in the very early stages of the reconciliation of them and the Bitcoin technical community (or at least those interested in working on covenants) doesn’t even remotely show any signs of consensus around any concrete proposal, talking about a “way forward for CTV” or activating CTV or coming up with some way of shoving it into Bitcoin at this stage is insulting, myopic, short-sighted. Worse, it sets incredibly poor precedent for how we think about changes to Bitcoin and maintaining Bitcoin’s culture of security and careful design. I’m gobsmacked that the conversation has reached this point, and am even more surprised that the response from the Bitcoin (technical) community hasn’t been a more resounding and complete rejection of this narrative.
At this point it is not clear to us that Jeremy’s activation proposal will succeed or even gain significant traction. However, he is certainly willing to step his neck out and generate a degree of drama, when it comes to Bitcoin’s consensus rules. As Jeremy indicated to us above, this is the season for such shenanigans. It’s approaching summer after all.