Analyzing BIP119 And The Controversy Surrounding It

The debate about BIP119 has two central issues being conflated: the proposal itself and the activation mechanisms that could be used to implement it.

This is an opinion piece about BIP119 (OP_CTV). If you would like to submit a counter argument, please email Bitcoin Magazine.

BIP119, or Check Template Verify (CTV), has been the center of an absurd and ridiculous controversy in the last week or so. There are two aspects of what is currently driving this controversy, the CTV functionality itself and the floated idea of activating it in the short term utilizing the controversial Speedy Trial mechanism that was successful in activating Taproot. These two issues have been conflated to the point that trying to disentangle them and discuss either one separately has become, to put it lightly, an incredibly challenging endeavor.

As one of the people involved in supporting a user-activated soft fork (UASF) client for Taproot activation that was compatible with the Speedy Trial (ST) deployment, I can say wholeheartedly that I am very much against future use of ST as an activation mechanism. I see it as a horrendous mistake and something that socially puts the perception of a veto mechanism and over-weighted influence in the consensus process in the hands of miners. I believe that activation of consensus changes should rest solely in the hands of users, not developers and not miners. That said, the issue of how to activate changes is only tangentially related to the CTV proposal, and much of the controversy centers specifically around the BIP itself and the general concept of covenants.

There is a great deal of confusion around what CTV can and cannot accomplish. Much of the criticism against the proposal itself that is not rooted in issues with the proposed activation or activation mechanism is based around the idea of degradations to fungibility, i.e., the potential for someone to send you coins and restrict where you are able to spend them. This is not possible for two reasons. Firstly, CTV restricts coins by EXACTLY defining where they have to go, and the exact amounts. To do something like “create whitelists” to limit where your coins are spendable, you would have to precompute every possible address someone would be allowed to spend coins, but then also for each of those addresses, compute every possible amount that could be conceivably spent to them down to the granularity of a satoshi. Secondly, the receiver is the one that provides an address to the sender, and the one who decides what exact Bitcoin script one must satisfy in order to spend the received coins. If a sender alters that script in any way, it alters the “address,” and the receiver’s wallet will not even recognize any funds as being received. It’s no different giving someone an address, and having them send money to someone else’s wallet. 

Presigned Transactions And Multisig

Presigned transactions are a very important component of building things on top of Bitcoin. Lightning is built on presigned transactions, statechains are built on presigned transactions and discreet log contracts are built on presigned transactions. Combined with multisig scripts, it is possible to guarantee that an existing UTXO encumbered by the multisig can only be spent in certain predefined ways. This is the entire basic core of these second layers.

All the parties involved generate a multisig address, then choose which UTXOs to fund it with. Before signing the funding transaction, they craft the transaction(s) that spend(s) the multisig UTXO in the predefined way(s), then they sign and confirm the funding transaction. Now, without all parties agreeing to change where to and under what conditions the funds are spent, nothing can be changed. The destination and conditions under which the funds will move to the destination are locked in. The major limitation of this primitive is that in order to guarantee those funds stay limited in how they can be spent, everyone who has contributed money or is dependent on those spending limitations must be a participant in the multisig contract. If they are not, then they must trust the parties actually involved in the multisig contract, or at least some threshold of them (for example, in the case of a 3-of-5 multisig, they must trust at least three participants to be honest). Without participating, they must trust participants to only sign honestly and/or to delete private keys without retaining copies.

What are the limitations of presigned transactions? You have to define every detail of the transaction: what it does, where it spends funds to, any transaction level timelocks, etc. You can never undo signing a transaction, you can’t change what you’ve already signed. This is why Lightning needs penalty keys, and people want ANYPREVOUT and eltoo, because you can’t undo or “take back” the previous signed transaction. All you can do is sign a new one and give it the ability to update or negate the previous one if someone tries to use it. Sometimes you may want to do this, sometimes you may want to make sure it’s not possible, but that previous signed transaction is locked in, and always possible to use as long as someone keeps it. You can never take it back.

CHECKTEMPLATEVERIFY / BIP119

The core functionality of CHECKTEMPLATEVERIFY (CTV) is to provide stronger guarantees in the situation where you want to ensure it is not possible to replace the initially signed transaction. Instead of having to trust multisig participants to behave honestly or key generators to delete private keys, CTV guarantees that spending a coin in the predefined way is literally enforced by consensus rules. This is accomplished by including the hash of the predefined transaction you want to spend that UTXO, and including it in the locking script for that UTXO when it is created. When you go to spend that coin, the script interpreter ensures that the spending transaction’s hash matches what was in the input’s script, and if the hash does not match it fails the transaction as invalid by consensus.

This provides the same functionality as multisig and presigned transactions in the use cases where you want to guarantee the initial transaction set cannot be replaced, except it completely removes the requirement to trust participants in the multisig quorum to act honestly or someone to delete private keys after signing transactions. It does not open any new doors, it does not enable anything that cannot already be done with presigned transactions and multisig; it simply removes the need to participate directly in the multisig script in order to not have to rely on trusting third parties to enforce the correct execution of the contract.

CTV does no more to enable forced implementation of “whitelisting restrictions” so that coins can only be spent to approved addresses than presigned transactions do. The number of different combinations of amounts, destination addresses and specific variables that can differ in spending transactions that have to be precomputed and signed ahead of time to do something like this is absurdly burdensome and impractical to do for every withdrawing user ahead of time. That is also completely ignoring the fact that each change output of each precomputed transaction would have to to be similarly encumbered with an almost infinite number of these combinations, and the change outputs from the next set of transactions, and so on, and so forth, into what is effectively infinity. The only optimization CTV offers is not having to spend the CPU cycles signing things, which does nothing to change the fact that this in practice is just completely intractable. Why deal with all this complexity and precomputation instead of just refusing to let users withdraw except to a 2-of-2 multisig where the exchange holds a key so they can refuse to authorize “bad transactions?” Or just not let users withdraw at all? 

The Choice

Ultimately the choice of what to activate or enforce comes down to what each individual user chooses to do with their node and the cumulative result of that across the entire network that each of those individual choices adds up to. That is how Bitcoin works, and nothing will change that — short of a complete breakdown of independent thought and decision-making among users. That said, it would be a real shame, in my opinion, for a proposed upgrade to be torpedoed and shot down based on a complete misunderstanding of what it can and cannot do, as opposed to reasoned and rational criticisms of potential downsides, inefficiencies or risks it presents to the network. In my opinion, that would not be a display of users’ self sovereignty or independent verification of facts asserted by public figures, but a display of outright stupidity and ignorance.

I hope going forward that this conversation can be properly separated into the two issues being currently conflated — the proposal itself and the activation mechanisms that could be used to implement it — instead of the current situation where these two things are being wildly conflated and not recognized for the separate issues they are. At the end of the day it is a perfectly rational and reasonable thing to not support a change based on the risks of soft fork activation itself or because of legitimate shortcomings or risks an individual proposal presents to the network. However, I do not think it is reasonable to voice a lack of support rooted in completely nonfactual assertions about a proposal and what it can actually do, while in the process, spreading misinformation about the proposal itself to people who are currently attempting to learn about and understand the proposal to make their own decision. That is something I would call an attack on the consensus process.

Bitcoiners should not feel the need to spread lies and misinformation in order to convince people to take the same positions or act in the same way as themselves.

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.