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.

I stated in that post:

“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.

Jeremy has put up this site (https://utxos.org/signals/) which is collecting 
so-called “soft signals”. I very much doubt anyone has a problem with Jeremy 
engaging with the community on his proposal and receiving feedback. However, 
the site currently states:

“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 

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.


[1]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

[2]: https://rubin.io/bitcoin/2021/12/24/advent-27/

[3]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki

[4]: https://yakshaver.org/bitcoin/#anyprevout


Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
bitcoin-dev mailing list

Reply via email to