Exploring BIP119 And Changes Made To Bitcoin
This is an opinion piece about BIP119 (OP_CTV). If you would like to submit a counter argument, please email Bitcoin Magazine.
In the past few weeks, there has been an effort to push a Bitcoin Improvement Proposal (BIP) forward by the name of CTV or BIP119. In this article I will attempt to do two things. First I’d like to describe the important properties of CTV, and secondly, I’d like to disentangle the two debates that are happening concurrently within the Bitcoin community right now.
In Bitcoin, we should take the “Don’t Trust, Verify” imperative seriously. As such, anything I say in this article should be cross-validated against the original BIP119 text as well as the pull request implementing it.
Further, while what I say should be able to stand on its own, irrespective of any credentialing, I will note that I have been working on Bitcoin technologies and Bitcoin directly for almost five years as of the publishing of this article. This does not make me immune to errors, but it should at least help convince you that this article is coming from an informed view and that reading it is worth your time.
Disclosure: I am publicly on the record as supporting the activation of BIP119 on Bitcoin mainnet. It is impossible for me to give you an “unbiased” take. However, I will do my best to make it clear what is a fact and what is an opinion.
Finally, this article assumes a basic familiarity with how Bitcoin works, the structure of transactions and the scripting system in Bitcoin.
So what is CTV? CTV, short for CheckTemplateVerify, is a proposed consensus change to Bitcoin. The proposal would effectively add an operation to Bitcoin’s script system that would prevent a coin from being spendable unless it was being spent in a transaction that had a particular “template.”
This is a fundamentally new capability for the Bitcoin script system and this is partly why the proposal has stirred up a bit of controversy. As of the publishing of this article, all of the spending requirements you can place on Bitcoin are either time-based (CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY) or they are requirements placed on the “witness” (the evidence you present to the Bitcoin network that proves you are allowed to spend the coins).
None of the opcodes you can use in Bitcoin script today allow you to specify any requirements on the transaction that spends those coins. The category of designs and opcodes that do place restrictions on the transactions themselves is often referred to as “covenants.” There are many other proposals that fall in this category that are being discussed by the Bitcoin development community, but what are covenants and why would I want them?
The most important thing to understand about covenants is that they allow you to place restrictions on the outputs of the transactions that spend the coins that are bound by them. Recall that Bitcoin transactions are a collection of inputs (coins you are trying to spend), a collection of outputs (where you are trying to spend the coins) and a witness (proof that you are allowed to spend those coins).
Being able to specify the possible ways you wish to spend your coins in the future can allow you to create more secure cold storage solutions. For example, let’s say that you never want to withdraw more than 10% of your cold storage coins per month. With covenants you could structure your spend conditions such that one month after deposit, you could only spend your coins in one of two predetermined ways: either 10% goes to a predefined hot wallet address and the remaining 90% goes to a new cold storage setup that is similarly structured, or all 100% goes to a new cold storage setup that is similarly structured. The value of this type of arrangement is that you can be sure that even if your system was compromised you would only be risking 10% of your funds before you had a chance to react. This use case is very often referred to as a “vault.”
This is not the only use case for covenants, though. You need covenants to do a number of contracts that “carry state.” I do not have the ability to go into a long list of use-cases here, and there are better materials on the web for that.
Back to CTV, specifically. How does CTV actually work? CTV takes the top item on the Bitcoin Virtual Machine’s stack and verifies that the “template hash” of the current transaction matches that value. This necessarily means that if you wish to spend the coins protected by CTV, you must have known the template hash of the spending transaction before depositing funds into the CTV protected address.
Why is this? Since the template hash of the spending transaction is embedded in the script you are sending your coins to, and because hash functions are one-way, you had to know this value up front: Solving for it after the fact would be equivalent to breaking Bitcoin’s mining algorithm.
As a result of this design, CTV has a property that makes it much simpler than some of the competing proposals. First, all “exit paths” of a CTV contract are known up front. This makes analysis of the safety of CTV contracts significantly easier and therefore less likely to lock your funds up forever.
Before we wrap up the discussion of how CTV works, let’s talk about what goes into the “template hash,” as this is ultimately what you are having to commit to before generating the CTV contract. The template hash covers the transaction’s version, locktime, number of inputs, sequence numbers, number or outputs, the hash of the outputs and values. This is every part of the transaction except the exact input IDs and the witnesses. Essentially, this means you have to know the exact transaction you want to use to spend these coins. This gives the design very little wiggle room in which there could be bugs in the design that allow for vulnerabilities. This is another reason why CTV has a much smaller surface to analyze than other proposals.
So where does the technical community stand on the subject right now? There seems to be broad agreement within the technical community that some mechanism for covenants is desirable. Where the disagreement remains is whether or not CTV, specifically, is the best next course of action or whether other proposals would afford a better set of trade-offs.
Many people are advocating for doing a bunch more research into alternative schemes for adding covenants to Bitcoin. This is noble in principle. However, I first learned of CTV at Bitcoin2019 which is just about three years ago now. So while it is a new idea for a lot of folks, there is a set of people who have been discussing this for years and are justifiably trying to figure out what the appropriate next steps are. Nevertheless, it is important for Bitcoiners to maintain a culture of skepticism when it comes to proposed consensus changes. That is what makes Bitcoin strong.
If you have read this far and still don’t find the story for CTV compelling, that’s fine. Usage of any opcode in Bitcoin is opt-in. The existence of the multisig opcode does not force you to use it, and CTV is no different in this respect. CTV also has no means of changing the way your current coins can be spent. You must take action to move your coins to a CTV address if and when it is activated in order for it to impact your ability to transact on the Bitcoin network.
I usually call these kinds of changes “non-invasive” because they only affect you if you want them to. Further, I’d like to make the case for wanting to be amenable to these kinds of changes, even if you don’t yourself wish to use them: You may be the one who wants a non-invasive change sometime in the future and building a culture of cooperation will help more people get what they want. If a change does harm you or change some property of Bitcoin that is important to you, you should absolutely resist, but not every change is like that and in my professional opinion CTV isn’t either.
So where’s the controversy in all of this? For the remainder of this article I want to refocus away from CTV itself and talk about the activation procedure. This is really where the meat of the debate is. The first part of the controversy stems from the fact that many believe that an attempt to activate CTV this summer is too soon. If you’re just hearing about CTV now, this is probably how you feel. As I mentioned earlier, for some people, this has been a proposal in-the-making for around three years. This is where the fundamental tension lies.
In Bitcoin, it is nearly impossible to figure out how much support there is for a proposal without just trying it. Everyone’s individual view into the social consensus is colored by their connections in the network. Everyone’s view into social consensus is unique and valid, but ultimately incomplete. There is some research for how to improve our collective understanding with where people are, but the same things that make Bitcoin uniquely special also make this particular problem devilishly hard to solve in a way that people would agree is fair. Despite this, we have activated consensus changes as recently as last year. Even though Taproot has been activated for months, there are still people who don’t really understand what it enables, much less how it works.
Even though there seems to be this lack of education surrounding what Taproot’s properties are, there doesn’t seem to be anyone upset about its activation. I suspect the reason for this is that there was near unanimous consensus in the technical community that Taproot was a good idea and the consensus and activation code was formally released in a Bitcoin Core release, which I believe contributed to people being more amenable to it.
This is in contrast to the current situation which I’ll get into in a moment. But before I do, there’s one thing I want to make clear about the story of Taproot: Even though there was overwhelming support for the activation of Taproot, the method of activation was (and still is) hotly contested.
This reveals something about the CTV debate as well. Namely, that there are actually two debates happening. First, there is the debate that aims to answer the question, “Do we want CTV to be activated at all?” Second, there is the debate that aims to answer the question, “Assuming we want CTV, what is the appropriate way to activate it?” Jeremy Rubin, the author of the CTV proposal (BIP119), wrote an article on his blog explaining his rationale for his next steps, which included plans for releasing a Bitcoin client, based on the newest version of Bitcoin Core, that contained code that would activate CTV as early as 2022.
While the code that is responsible for the activation is taken straight from the Taproot episode, an important difference here is that CTV hasn’t been merged in Bitcoin Core, nor has its activation code. These plans have since been abandoned in response to the controversy which indicates pretty strongly that there is a lack of consensus. That said, in my view, the process of trying stuff, incorporating feedback and then trying again is how consensus gets built. After all, had no one advocated for Taproot, it still wouldn’t be live on the Bitcoin network today.
So where does this leave us? Current activation attempts for CTV have been abandoned in an attempt to let public discussion build consensus. The merits and flaws of CTV should be and will be discussed for the next several months. In parallel, there are numerous discussions on how softforks should be treated going forward such that Bitcoin can still reasonably improve while minimizing the chances of letting the process be hijacked by actors who wish to materially alter Bitcoin’s purpose.
This is a guest post by Keags. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.
