From: Anthony Towns <aj@erisian•com.au>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Date: Sat, 6 Mar 2021 21:33:26 +1000 [thread overview]
Message-ID: <20210306113326.mrftlkmmloy2dsag@erisian.com.au> (raw)
In-Reply-To: <281679eb-860b-c6cb-7e7a-5ae28b60f149@mattcorallo.com>
On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote:
> On 3/3/21 09:59, Anthony Towns wrote:
> > A couple of days ago I would have disagreed with this; but with Luke
> > now strongly pushing against implementing lot=false, I can at least see
> > your point...
> Right. It may be the case that the minority group threatening to fork off
> onto a lot=true chain is not large enough to give a second thought to.
> However, I'm not certain that its worth the risk, and, as Chris noted in his
> post this morning, that approach is likely to include more drama.
I think there's two different interpretations of what a "user-activated
fork" means:
1) if people try to take bitcoin in a direction that risks destroying
it, it's possible to ignore both devs and hashpower entirely and force
a chain split to ensure it's possible to continue transacting with
"the real bitcoin".
2) removing miners' influence over consensus rules entirely -- so that
not only can users overcome miner objections by risking a chain split,
but so that miners don't have any greater ability to object than
anyone else in the ecosystem.
In my opinion, bip8's optional lockinontimeout setting and must-signal
approach is well-designed for case 1; if miners object for good reasons,
then there is no need to override them (if there's a good reason not to do
something, it shouldn't be done!), while still having the possibility to
override them if they object for bad reasons. Because hashpower disagrees,
there's always a risk of a chain split in that case, so the additional
risk introduced by a signalling requirement is pretty minimal. That the
lockinontimeout value is a setting means it can be switched only when
we're sure there aren't good reasons for the objection.
There is a lot of work to be done to make bitcoind have an acceptable
chance of gracefully *surviving* a network split introduced by this sort
of conflict; but provided no one started setting lockinontimeout=true
until we were six or so months into an activation attempt (and hence
had the opportunity to judge whether the reasons for not activating
were bad), that would likely be enough time to start implementing some
safety mechanisms.
But there seems to be much more signficant support for the case 2 than I
expected; as evidenced by the "let's do lockinontimeout=true immediately"
advocacy, eg:
I am not willing to go to war for Taproot. I'll be honest the reason
I'm interested at all is that devs I respect spent a lot of energy and
time on it and I was reluctant to let their marginally beneficial work
go to waste.
I am, however, willing to go to war against LOT=False.
-- https://twitter.com/francispouliot_/status/1363876292169465856
I don't think bip8 is well-designed for that approach: most importantly,
with early adoption of lockinontimeout=true, bip8 *encourages* a consensus
split in the event that good reasons for not activating are discovered
afterwards, because lockinontimeout=false nodes remain able to abandon
the activation attempt. Consensus splits are terrible; they should be
a last resort used only in the event that bitcoin's fundamental nature
is threatened, not a standard risk if bugs happened to be discovered
late. But additionally, if we are worried miners might not be acting
in the interests of all bitcoin users, there are other games they could
play, such as "if you want X activated quickly, also give us Y; otherwise
we'll delay it as long as possible".
Losing the opportunity to abandon an activation attempt, by whatever
mechanism, also puts a lot more pressure on being absolutely sure of the
desirability of the change at the point when it's merged; because miners,
third-party devs, businesses, and users don't even have the option of
attempting to influence miners, all objections needs to be raised when
the activation parameters are merged, which raises the stakes for that
event substantially.
I think my conclusions from that are:
* as it stands, people are expecting to run bip8/lot=true nodes on the
network immediately; so deploying bip8/lot=false with compatible
parameters risks causing consensus splits, and should not be done
* David Harding's "speedy trial" approach probably doesn't suffer from
the problems -- running a lot=true variant would require enforcing
signalling prior to the end of July, which is an unreasonable timeframe
to expect the majority of economic nodes to upgrade in; if bip9 is
used, then the risk of enforcement occuring with minority hashrate
(and thus having fewer retarget periods before the timeout is
reached) would also make a bip148/lot=true variant difficulty
* if people want a "taproot is guaranteed to activate no later than X"
PR merged, someone needs to do a *lot* more outreach to be sure that
that's the right outcome, and it's not just devs/maintainers making
the call
* IMO, Matt's proposed approach is both a better and simpler approach
to avoid giving miners undue influence on consensus; as such I've
drafted up a sample implementation:
https://github.com/bitcoin/bitcoin/pull/21378
(Backporting it to 0.21 just requires backporting #19438, which is
straightforward)
So I think that means my preference is to do the "speedy trial" with
signalling first, and if that fails, then either we've established there
are real problems with taproot and will go back to the drawing board to
fix them, or if we have not found problems by that time we should simply
switch to a straight flag day activation as Matt proposes. Presumably
we'll have established broard community consensus for activation if no
objections are discovered during the speedy trial.
Cheers,
aj
next prev parent reply other threads:[~2021-03-06 11:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-28 16:45 Matt Corallo
2021-02-28 17:20 ` Luke Dashjr
2021-02-28 17:29 ` Matt Corallo
2021-02-28 19:43 ` Jeremy
2021-02-28 19:51 ` Matt Corallo
2021-02-28 20:02 ` Jeremy
2021-02-28 20:19 ` Eric Voskuil
2021-02-28 20:25 ` Matt Corallo
2021-02-28 20:38 ` Eric Voskuil
2021-02-28 20:20 ` Matt Corallo
2021-03-03 14:59 ` Anthony Towns
2021-03-03 16:49 ` Matt Corallo
2021-03-06 11:33 ` Anthony Towns [this message]
2021-03-08 12:51 ` Jorge Timón
2021-03-08 14:13 ` eric
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=20210306113326.mrftlkmmloy2dsag@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/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