Return-Path: <luke@dashjr.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F348EC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 19:45:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D60F86061D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 19:45:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.25
X-Spam-Level: 
X-Spam-Status: No, score=0.25 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.35,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=dashjr.org
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bjfNIYFjJyAm
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 19:45:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
 by smtp3.osuosl.org (Postfix) with ESMTP id E46C660612
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 19:45:30 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.214])
 (Authenticated sender: luke-jr)
 by zinan.dashjr.org (Postfix) with ESMTPSA id A1F9338A00A5;
 Sun, 28 Feb 2021 19:45:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
 t=1614541530; bh=ilgJpRlhp46jc/fmT/JrEEnHRYbdWvIV/uYSYe7+jLA=;
 h=From:To:Subject:Date:Cc:References:In-Reply-To;
 b=ONx7KMfAdDIcUZqvtgdCX39uk0xWexfkpojSj45FsaQE5KAWHZ/+qBefeG4kw502w
 swMa4MhFSdgM8pzTNDRgJcNIKKl9nqRXXsdLpwPI5rtEcIVo5zWKfso6Jg/OHnGwL5
 boA4Ek5ge7GpfDgwF/2FcZc1Xhs7bjLdCYAp7kxo=
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>
X-KMail-QuotePrefix: > 
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Feb 2021 19:45:32 -0000

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