I have already expressed my arguments on the regularity of soft forks [0]. Having spent months of my time on Taproot activation last year attempting to get at least rough community consensus on the activation method it seems crazy to me that some want to do that again so soon after Taproot activation and somehow this time it will be plain sailing. (Spoiler: it won’t. Although Taproot safely activated there remain outstanding views ranging on whether BIP 8 or 9 variants of Speedy Trial should be used in future to Speedy Trial only being a short term stopgap that should not be repeated.) If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.

“A contentious or disputed soft fork can be merged into a Bitcoin implementation at any time but doing this is opening the door to the schism, disruption and waste of developer hours that we saw in 2017. Personally I think we’ll see an attempt to activate a contentious soft fork at some point in the long term future (Murphy’s Law) but any attempt to do so should be strongly discouraged. It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem. Longer term I have confidence in Bitcoin’s ability to survive whatever happens but allocating significant community resources to resist an unnecessary contentious soft fork (or even regular contentious soft forks) is not an optimal use of those resources.”

I am getting increasingly concerned that we are stumbling into this scenario three months after I wrote that post. One of many future soft fork proposals (as many will know) is BIP 119 [1] which is the enabling of a new opcode OP_CHECKTEMPLATEVERIFY (OP_CTV). It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2]. To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4]. Similar work has not been done for any of the speculated use cases of OP_CTV. Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.

This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible. I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day. It is true that Jeremy has some rudimentary proofs of concept built but as any software engineer will tell you the vast majority of the challenges are encountered once you attempt to build out that proof of concept. Once you do you may realize that the tool (or opcode) you are using isn’t the right one for the job. Unlike adjusting a feature on a social media app adjusting a consensus change once it has been activated is trickier to put it mildly.

There are a number of other more interesting technical discussions to be had later (what kind of covenants we want and are able to enable safely on Bitcoin etc, how CTV compares to other covenant enabling proposals, to what extent activating CTV would impact future proposals) but I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.

“The following organizations, individuals, or pools have communicated preference for and intent to support a BIP-119 activation attempt using reasonable parameters. These “soft signals” are non-binding until an actual concrete proposal has been formed, but are useful for measuring community consensus.”

There have been a number of “soft signals”, many expressing enthusiasm for the speculated use cases of OP_CTV. Personally I share that enthusiasm like I do with the prospect of curing cancer. But these soft signals seem as if they are going to be used to attempt to justify an imminent contentious soft fork attempt. The devil is in the details both with regards to wording like “reasonable parameters” and the utility and safety of a new opcode. Indeed if you share my concerns that there has not been sufficient scrutiny and research on the long implications of this proposal I encourage you to register a soft signal of “No” on the site like I have. You can always change it to “Yes” if and when you support an imminent soft fork activation attempt containing exclusively OP_CTV. Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted. To look at the ~200 lines of code for the opcode exclusively (of course this should be done too) in a vacuum without considering the broader implications is also incredibly shortsighted. The only thing stopping a descent into Ethereum style seat of our pants consensus changes is community vigilance. If we ever lose that we lose the foundation of this industry.