Date: Mon, 29 Mar 2021 19:17:57 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210329091757.GA13603@erisian.com.au>
References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
 <CAMZUoKkWmdwi-VH3WUvFfG+5MDK3xhvZUac3eBQbxXX_b_btWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMZUoKkWmdwi-VH3WUvFfG+5MDK3xhvZUac3eBQbxXX_b_btWw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
Precedence: list

On Wed, Mar 03, 2021 at 02:08:21PM -0500, Russell O'Connor via bitcoin-dev wrote:
> While I support essentially any proposed taproot activation method, including a
> flag day activation, I think it is premature to call BIP8 dead.
>
> Even today, I still think that starting with BIP8 LOT=false is, generally
> speaking, considered a reasonably safe activation method in the sense that I
> think it will be widely considered as a "not wholly unacceptable" approach to
> activation.

If everyone started with lot=false, that would be true -- that was how
segwit then BIP148/BIP91 worked, and was at least how I had been assuming
people were going to make use of the new improved BIP8.

But it seems more likely that when activation starts, even if many
people run lot=false, many other people will run lot=true: see Luke's
arguments on this list [0], Rusty's campaign for a lot=true option [1],
the ##uasf channel (initial topic: Development of a Taproot activation
implementation with default LOT=true) [2], or Samson's hat designs [3].

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
[1] https://rusty.ozlabs.org/?p=628
    https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3667311
[2] http://gnusha.org/uasf/
[3] https://twitter.com/Excellion/status/1363751091460956167

With lot=false and lot=true nodes active on the network, a chain split
occurs if the activation is blocked: perhaps that might happen for good
reasons, eg because there are implementation bugs found after activation
settings are merged but prior to activation locking in, or perhaps for
neutral or bad reasons that cause miners to be opposed.

In the event of a huge conflict or emergency as bad as or worse than
occurred with segwit, a chain split might well be the lesser evil
compared to the activation being blocked or delayed substantially;
but as default scenario for every consensus change, before we know if
someone might find a problem while there's still time to back out, and
before we know if there is going to be a huge conflict? It doesn't seem
as focussed on safety as I'd expect from bitcoin.

> After a normal and successful Core update with LOT=false, we will have more
> data showing broad community support for the taproot upgrade in hand.  In the
> next release, 6 months later or so, Core could then confidently deploy a BIP8
> LOT=true client, should it prove to be necessary.

BIP8/lot=true is great for the situation we found ourselves in with
BIP91/BIP148: there's an activation underway, that is being unexpectedly
opposed, we want to ensure it activates, *and* we don't want to have
everyone have to do a new round of software upgrades.

But if we're able to calmly put out a new release with new activation
parameters, with enough time before it takes effect that everyone can
reasonably upgrade to it, that's a pretty different situation.

First, since we're giving everyone time to upgrade, it can be a clean
secondary deployment -- there's no need to try to drag the original
lot=false users along -- we're giving everyone time to upgrade, and
everyone includes them.

Second, lot=true implies we're doing some unsignalled consensus change
anyway -- blocks would be considered invalid if they don't signal for
activation as of some height, with no prior on-chain signalling that
that rule change has occurred. So if we're allowing that, there's no
principle that requires signalling to lock in the change we're actually
trying to activate.

So at that point why not simply reverse the burden of proof entirely? Run
an initial "speedy trial" type event that allows fast activation via miner
enforcement prior to everyone having upgraded; and if that fails but there
haven't been valid reasonable objections to activation identified, run
a secondary activation attempt that instead of requiring 90% signalling
to activate, requires 90% signalling to *fail*.

Miners not upgrading is then not a blocker, and even if a few miners are
buggy and signal accidently, that doesn't cause a risk to them of having
their blocks dropped, or to the network of having the upgrade blocked.

If there are good reasons to object to the fork being activated that are
discovered/revealed (very) late, this also provides an opportunity to
cleanly cancel the activation by convincing miners that the activation
is undesirable and having them agree to signal for cancellation (via
BIP-91 style coordination or even BIP-148 style mandatory signalling, eg).

And, on the other hand, if 90% of miners are opposed to a soft fork for
some selfish or bad reason, with that much hashpower they could easily do
a 51% attack on the network after activation to prevent any new features
being used, so cancelling activation in that case is probably not worse
in practice than it would be continue with it despite the opposition.

I think a state machine along the lines of:

  DEFINED - for 6 months after code release
  STARTED - exactly 1 period
    FAILED - if sufficient signalling occurs
  DELAYED - 6 months
  LOCKED_IN - exactly 1 period
  ACTIVE

would work fine for an if-at-first-you-don't-succeed approach to
deployment along the above lines.

That seems to me to have a lot of desirable properties:

 - a minority of hashpower can't block activation

 - miners don't have to do anything and don't have to worry about
   their blocks getting orphaned
   
 - devs aren't making any final decisions on consensus changes,
   even if everyone's committed to running the same codebase
   (unlike when merging either lot=true or flag day activations)

 - there's no need to run different clients, or carefully configure your
   node to stay in consensus

 - if economic actors want to influence activation by setting up
   markets, they have a single signalling period to focus on, with 6
   months lead time to set everything up and stabilise price discovery,
   and a fairly definite endpoint and clear result for closing out
   everyone's positions, whichever outcome occurs

 - there's no need/encouragement to use the machine vetting your business
   income as leverage to force/prevent changes to bitcoin consensus;
   configuring your node to not follow the most work chain is only
   needed when both devs and miners are getting it wrong, *and* market
   incentives haven't been enough to correct things

The main drawback is that it doesn't allow faster activation with miner
support; even with a speedy trial first, it's just a boolean: did miners
indicate they've upgraded quickly enough to hit the early activation
or not?

Cheers,
aj