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.
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.
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.
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.
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
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.
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. [...] Without an OP_CTV type upgrade, it is difficult to see how to achieve this kind of feature in Bitcoin.
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
Bitcoin developer Matt Corallo explained his strong opposition [...]
"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."