From: Michael Folkson <michaelfolkson@protonmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] On the regularity of soft forks
Date: Mon, 11 Oct 2021 12:24:10 +0000 [thread overview]
Message-ID: <LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=@protonmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 7662 bytes --]
I was hoping to delay this post as long as possible because there are so many interesting and important things to discuss other than soft forks and consensus changes that seem to have taken a backseat this year due to Taproot activation. In addition, there seems to be a world of opportunity to leverage the upcoming Taproot soft fork that risks getting drowned out by speculating on the next soft fork.
There is clearly nothing wrong with some individuals continuously working on, designing and refining new possible consensus changes and whoever is interested is free to follow and participate in those discussions. This is Bitcoin, no one let alone me can decide what people should focus on. Indeed I intend to allocate a portion of my time to following and understanding the trade-offs of current and future soft fork proposals. However, in this post I will argue against frequent soft forks with a single or minimal set of features and instead argue for infrequent soft forks with batches of features.
I fully understand the desire and motivation to get consensus changes into Bitcoin as quickly as possible when certain use cases depend on them. However, the robustness, security and ability to resist harmful or suboptimal changes to the system is clearly the ultimate priority. The more frequently soft forks are attempted the harder it is for the community to ensure harmful or suboptimal changes don’t creep into the consensus rules. I am well aware of how much community mindshare Taproot activation demanded this year. This is how it should be. The community should be informed and vigilant when the consensus rules are changed. Every full node will either immediately on activation or in future enforce these consensus rule changes and so it is in the interests of every full node operator that these changes have been subject to the ultimate levels of community review and rigorous testing. Attempting them frequently either requires continuous community monitoring or an acceptance that an unneeded or harmful consensus change could easily creep into Bitcoin. Neither of these options seem acceptable to me. It is not reasonable to ask all the different segments of the community to dedicate full time resources to stay on top of proposed consensus changes. Hence treating a pull request to a Bitcoin implementation that requires a soft fork like any other pull request is shortsighted.
Merging soft fork code into a Bitcoin implementation
The code for a soft fork should not be merged into a Bitcoin implementation, let alone activation parameters (discussed later), until the maintainers of that implementation are comfortable that the entirety of that soft fork has sufficient community consensus. This includes what many consider the reference implementation and dominant implementation on the network, Bitcoin Core. A soft fork pull request cannot and should not be treated like any other pull request which can be merged with anything from 1 to 10 ACKs from long term or newer contributors. The act of merging a pull request that is part of a proposed soft fork is an acknowledgement by the maintainer(s) of that implementation that they consider the entirety of that proposed soft fork to have community consensus. That includes what is included in that soft fork as well as what isn’t. If there is a prevailing view that the current design could be improved, could feasibly be replaced by something superior in future or merely hasn’t been subject to sufficient community review it should not be merged.
Of course there is no ultimate authority to enforce that this happens, Bitcoin is an entirely voluntary system. 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.
Soft fork activation
Miner signaling is a tool for signaling readiness. It is not voting for the soft fork or expressing support for the soft fork. There should not be any attempt to facilitate miner signaling until there is sufficient community consensus (the mining community is a subset of the community) on the soft fork. Merging activation parameters or encouraging miner signaling before it is clear there is community consensus on the entirety of the soft fork is putting the cart before the horse.
Taproot showed it was possible through the sustained efforts of many individuals and many organizations to achieve overwhelming community consensus for a soft fork. It is obviously impossible to get 100 percent consensus but Taproot appeared to get close to that. I did not identify any resistance whatsoever to merging Taproot PRs or the objective of getting Taproot activated although there was one long term contributor who effectively NACKed Taproot based on quantum resistance concerns.
Activation method and activation parameters ended up being more challenging to obtain overwhelming community consensus. Although I and a number of others participated in multiple open IRC meetings and spent months on IRC trying to find a way to get Taproot activated with at least rough consensus a number of disagreements remain. I don’t think these are necessarily showstoppers for future soft forks and assuming Taproot activates safely next month they ended up not being showstoppers for Taproot. However, it is clear the bar that was achieved regarding community consensus for the Taproot soft fork wasn’t met for the activation method and activation parameters. In a world where there isn’t overwhelming community consensus on the activation method, the activation parameters and what to do if the first activation attempt fails we have to accept that soft fork activations contain downside risk on top of the already acknowledged risks of bugs, consensus divergences and botched implementations of soft fork features. To layer on top a level of uncertainty over whether there is community consensus for the actual soft fork seems unacceptable to me.
This is an important additional argument for infrequent soft forks with batches of features rather than frequent soft forks with a single feature. If there is a chain split risk every time you attempt a soft fork you should not casually attempt a soft fork frequently or with abandon. There has to be community consensus that the upsides of the soft fork are sufficient to take on these downside risks of disruption or worse chain splits. I was of the strong personal view that the upsides outweighed the downside risks for Taproot activation in 2021 but this is a judgment we as a community will have to make for each and every future proposed soft fork. It is easy to get excited about shiny new features. It is harder to ensure harmful or suboptimal changes don’t creep into the consensus rules and harder yet to minimize the risk of chain splits if soft forks are attempted frequently.
--
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: 9042 bytes --]
next reply other threads:[~2021-10-11 12:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 12:24 Michael Folkson [this message]
2021-10-11 19:12 ` Jeremy
2021-10-11 19:53 ` ZmnSCPxj
2021-10-14 23:52 ` Anthony Towns
2021-10-15 0:43 ` micaroni
2021-10-16 11:02 ` Michael Folkson
2021-12-31 3:10 ` Keagan McClelland
2021-10-11 16:03 Prayank
2021-10-12 19:04 ` Jorge Timón
2022-01-01 15:45 vjudeu
2022-01-18 16:00 ` Billy Tetrud
2022-01-18 17:22 Prayank
2022-01-19 2:26 ` Billy Tetrud
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='LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=@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