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
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.
[0]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
[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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
