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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
