From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, "David A. Harding" <dave@dtrt.org>
Date: Sun, 28 Feb 2021 19:45:23 +0000
User-Agent: KMail/1.9.10
References: <CAFvNmHSnd4OM+c0_L8fFXRNrxo23WdQpNdBjTJjhmGuHumgLDA@mail.gmail.com>
 <20210213163257.uvn4apdy4znr7p2t@ganymede>
In-Reply-To: <20210213163257.uvn4apdy4znr7p2t@ganymede>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <202102281945.24039.luke@dashjr.org>
Cc: Michael Folkson <michaelfolkson@gmail.com>
Subject: Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th
	February 19:00 UTC
Precedence: list

Answering the F1-F7 arguments for LOT=3DFalse...

> F1) The probability of Taproot not being activated by miners is small. Th=
is
> is not 2017, this is not SegWit, there is no need to worry.

While we believe miners have no reason to sabotage Taproot activation, this=
=20
was also the belief leading up to Segwit=E2=80=99s activation in 2017, and =
regardless=20
it is not desirable to create such a risk forcing the community to place=20
extra trust in miners. Miners might very well not exploit an inflation bug,=
=20
but that is no reason to purposefully add an inflation bug.

> F2) The worst case scenario is we have to wait over a year for Taproot to
> be activated. Even the worst case scenario is not a disaster.

While it is true that a second activation can be deployed in the event of t=
he=20
first one failing, doing so would not necessarily change the situation unle=
ss=20
LOT were changed to true anyway - in which case, it might as well be true f=
or=20
the initial deployment as well. Furthermore, a re-deployment could create a=
=20
situation where users believe they have already upgraded for Taproot, but d=
o=20
not enforce it due to not understanding the need to upgrade yet again.

> F3) If in the unlikely scenario miners did not activate Taproot for a year
> for no apparent reason we would never set LOT to false again for any
> potential future soft fork. If miners fail to activate Taproot despite
> pledging support and there being overwhelming community consensus for it,
> it would set a precedent that miners cannot be relied upon *at all* to
> activate soft forks.

Setting LOT=3Dfalse with a threat to change it to true later is antagonisti=
c=20
against miners. With LOT=3Dtrue, expectations are simply made clear and min=
ers=20
can simply cooperate by making valid blocks as they do day-to-day already.

> F4) If in the highly unlikely scenario that a bug or some problem with the
> Taproot implementation was found during the signaling period miners could
> choose not to activate it which is cleaner than needing an emergency Core
> release.

The risk that a bug in Taproot is discovered this late yet before activatio=
n,=20
to warrant aborting the deployment, is extremely low (much lower than the=20
risks created by LOT=3Dfalse). Even if such a scenario occurred, and even w=
ith=20
LOT=3Dfalse, users would still need to upgrade to back out the deployment. =
In=20
the best-case scenario, users would need to upgrade to deploy the fixed=20
Taproot. So in the end, nothing is to be gained from relying on a miner abo=
rt=20
for such scenarios.

> F5) LOT =3D false is more similar to what was done previously (unless you=
 go
> way back to the earliest soft forks which were more similar to LOT =3D tr=
ue)

The behaviour of LOT=3Dfalse has proven problematic and caused failure of S=
egwit=20
activation in 2017. LOT=3Dtrue behaviour has a long history of success, and=
 was=20
used to resolve and activate Segwit in 2017 after LOT=3Dfalse=E2=80=99s fai=
lure.

> F6) It is more important that no rules that harm users are deployed than =
it
> is that new useful rules are deployed quickly. If there is a choice betwe=
en
> =E2=80=9Cfaster=E2=80=9D and =E2=80=9Cmore clear that this isn=E2=80=99t =
a mechanism to force bad things on
> users=E2=80=9D we should prefer the latter. Plenty of people just don=E2=
=80=99t like
> LOT=3Dtrue very much absent evidence that miners are blocking deployment.=
 To
> some it just feels needlessly antagonistic and distrusting towards part of
> our community.

Any deployment, or even status quo, can be falsely portrayed/spun in a way =
to=20
harm Bitcoin. As such, only objective criteria should be considered.

BIP 8 makes it explicitly easy for people to reject the softfork if they do=
n't=20
like it, so any claim of being "forced" is a non-starter to an honest perso=
n.

> F7) defaulting to LOT=3Dfalse makes non-activation possible even if people
>     run the code that developers provide, meaning a successful
>     activation proves that at least some people (e.g. miners or UASFers)
>     voluntarily took actions that were well outside the scope of
>     developer control.
>
>     This makes it clear that developers don't control changes to the
>     system.  There are other arguments that demonstrate that developers
>     aren't in control[1], but they aren't as clear as simply pointing
>     out that a rule change won't go into effect until at least several
>     non-developers independently act of their own accord.
>
>     Having such a clear argument that developers aren't in control
>     bolsters the decentralized ethos of Bitcoin and reduces the chance
>     that bad actors will pressure Bitcoin developers to attempt future
>     unwanted changes.

Even if developers release software, it must still be accepted by the=20
community in the form of actively choosing to run the software which includ=
es=20
the activation. So long as the activation is clearly and prominently=20
documented, users have taken the action to accept the protocol change.=20
=46urthermore, the community has already demonstrated a clear and undispute=
d=20
support for the activation of Taproot. If there was/is any question of=20
whether that is true or not, it is premature to be planning activation of A=
NY=20
type.

Luke