The below is a direct excerpt of Marty’s Bent Issue #1198: “OP_CTV and rough consensus” Sign up for the newsletter here.
As I’m sure some of you are aware of by now, there is a heated debate happening amongst Bitcoin developers and users alike about OP_CTV, a subject we began covering here at the Bent in December 2019. OP_CTV, if enabled, would bring back to life an op code (OP_NOP4) with added restrictions. This would allow users to create complex covenants on Bitcoin that would enable more complex preconfigured transactions and could improve the user experience around security and batching a large number of transactions.
I think these are functionalities that would add utility to many bitcoin users, particularly larger economic actors who hold a lot of bitcoin that needs to have the highest degree of security as is humanly possible and those who send a lot of bitcoin to a large number of users on a daily basis.
With that being said, the attempt to get OP_CTV merged into Bitcoin Core has highlighted the murky nature of rough consensus within a distributed peer-to-peer system. The conversation around OP_CTV is forcing people to ask (myself included) questions like; is this completely necessary right now? Has there been enough discussion and review of the proposal? If so and it is deemed worthy, how should it be activated on the Bitcoin network?
After having spoken to a few developers who are familiar with both Bitcoin Core and the needs of some of the larger custodians it does seem that OP_CTV would be beneficial for many players in the space. The ability to leverage these types of covenants would expand the design space of the solutions they can offer customers because they have better security guarantees when moving large amounts of bitcoin. (I am using security in this context to mean “prevent human-error from leading to a loss of funds”.) I think OP_CTV would get used if it were activated.
Another variable that has been brought to light with the debate around OP_CTV activation (or refusal) is that the lead maintainers of Bitcoin Core, who have what’s known as “commit access” and are in charge of actually hitting the buttons that merges code into Bitcoin Core, do not seem to want any part in suggesting whether or not something should or should not be merged and how that should or should not happen. They seem to be adopting an increasingly neutral posture so that they don’t come off as partial and can be viewed as biased controllers of the codebase. This seems to be evident by their lack of willingness to provide Jeremy Rubin, the developer behind OP_CTV, with an answer to his question, “How do I go about getting this merged into Bitcoin Core?” I actually view this as a positive. It should be hard to change bitcoin and those who have the keys to the machine that allows you to change the most commonly used client should be as impartial as humanly possible.
Because of the refusal to deliver a straight answer to Jeremy in regards to an activation path, he has taken it upon himself to create his own client that has OP_CTV activated and provides users an avenue through which they can try to make OP_CTV official by participating in another User Activated Soft Fork (UASF) that leverages the Speedy Trial method of activation. While I understand Jeremy’s push to get OP_CTV activated, I’m not a big fan of pushing another soft fork via Speedy Trial. In retrospect, it seems that it was a bad precedent that was set when taproot was activated. I fear that normalizing a rapid succession of soft forks via Speedy Trial is a slippery slope that could lead to a lot of unnecessary changes in the future that could cause a degradation of the integrity of the bitcoin network.
While there are many people who would probably use OP_CTV if it were activated tomorrow, it doesn’t seem to be a pressing need at the moment. I am in favor of a more thorough conversation and debate about the merits of the feature and the precedents we set via its activation, if it comes to happen. I like the idea of OP_CTV but certainly do not think it’s a make or break feature at the moment.
I am in favor of murky rough consensus driving protocol changes over a well-defined process that could potentially be socially attacked. It will be interesting to see when and how this debate gets settled. One thing is for sure, I’m happy that OP_CTV is here to bring these tough but necessary conversations around consensus to the fore. These are very important discussions to be having.