1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
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
|
