From: Michael Folkson <michaelfolkson@protonmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
Date: Mon, 03 Jan 2022 02:05:20 +0000 [thread overview]
Message-ID: <XuO20TMFGBqz53WYWxi9bgAdB3iGmqEIUE84AupRxCpHQVd3-YbGVzZUFz21dOgb_AgwlGWaruzE8NGxhes6HCKHpRZLmL1d1kNu1yobAIU=@protonmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 6379 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 8458 bytes --]
next reply other threads:[~2022-01-03 2:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-03 2:05 Michael Folkson [this message]
2022-01-09 11:38 ` Peter Todd
2022-01-11 3:42 ` Jeremy
2022-01-11 4:38 ` Jeremy
2022-01-04 11:53 Prayank
2022-01-04 14:15 ` Michael Folkson
2022-01-04 15:06 ` Prayank
2022-01-04 16:48 ` Michael Folkson
2022-01-04 17:07 ` Prayank
2022-01-04 14:42 ` Christian Decker
2022-01-04 15:45 ` Prayank
2022-01-18 1:57 Prayank
2022-02-18 23:41 ` Peter Todd
2022-02-20 18:35 ` Erik Aronesty
2022-02-21 3:03 ` Prayank
2022-02-21 9:02 ` ZmnSCPxj
2022-02-21 9:11 ` ZmnSCPxj
2022-02-21 9:48 ` Prayank
2022-02-22 12:57 ` Billy Tetrud
2022-02-21 9:09 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='XuO20TMFGBqz53WYWxi9bgAdB3iGmqEIUE84AupRxCpHQVd3-YbGVzZUFz21dOgb_AgwlGWaruzE8NGxhes6HCKHpRZLmL1d1kNu1yobAIU=@protonmail.com' \
--to=michaelfolkson@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox