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
|
Return-Path: <michaelfolkson@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4FCBBC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Mar 2021 19:56:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 2A9BC839F9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Mar 2021 19:56:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level:
X-Spam-Status: No, score=0.602 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, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id es7Gu9-ijKd6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Mar 2021 19:56:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com
[IPv6:2607:f8b0:4864:20::32e])
by smtp1.osuosl.org (Postfix) with ESMTPS id 1A3BA839E5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Mar 2021 19:56:14 +0000 (UTC)
Received: by mail-ot1-x32e.google.com with SMTP id 97so5275919otf.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 06 Mar 2021 11:56:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to:cc;
bh=+AVny5b+W+afE9SqVnocKegfG5ThupHLK0L0C8rq7IE=;
b=FA1l/jhGD6Ayy81levCnmaxdO7f6CyYiwB5IweWnj2xUnNNmTaWiuUZgoy2bN0UN0f
6Gw9QfN96wKepn3FKre640XqfjsLCdu5AD8lKwLAMViKQFvyqTTr4gGaMq3y4orKXXuR
NOr8gZ7Vwyx0s31CXXHy2zbjwLPCuwAdpsameWVeVFxL3XQZA9ryWZISj+KBF5Bn1RWB
uGIwDnsl5r0ooZnTfErnq1ddlj+XKlZMbMJchoMQgfZ8UKpZN6W+j0I9dSwtctw39n0I
exrqygDejjmIqhcGoiMCVebvrrNP0l85Rhwasdm8GAt9pmbzf9v4KLOFf/2vUUEVaBiu
ykwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc;
bh=+AVny5b+W+afE9SqVnocKegfG5ThupHLK0L0C8rq7IE=;
b=VqIqW+9OVfrVQ44SHEL01kP5gYEfQZpoLGthxaxQHOqVEvmjkmQN3Fd1nSgNWrwDzj
V6yNkZ0YjpU+uurK+dIXScxGjADR3rHAf/GQnHc8SpLURutsVKfYwi/mFJgV8F2aNl13
5ZFeEHKJB+TgRzPD237XpcYoY0/ZC6p4/bqiueuiA4ehsghEvh8cVm6KYhGkhKZhIEGk
DRLoFM43GAukf06dXSZxFm9Oasxo4tbm0NhiuVuLZNlKCnv5yya7YVDENCdL3aLovbgu
WfkojrWkn8Paalm2JKxuvTzz7hTz4r/bO1AOJp/vopsG69/pU6IMgTc+uaD89w2AzN7+
pqQw==
X-Gm-Message-State: AOAM532uEGJhkanmB+8AoHlVYemm5L1AnIt95HT5gpl+ynqEhCw+7l1Q
5miiBMYWMFkaMSSq7VY5ktZpWWfSs6GS+Jlk88CRfHhCdsvOdg==
X-Google-Smtp-Source: ABdhPJy+5WYcuUnltASbJqdHCMi2Zf+jZ4SjPCmxdCyj5t5tz5KKCI69bh6rJyg0os7ld2MRFvVrMvG2Qs812DWO+JA=
X-Received: by 2002:a9d:7412:: with SMTP id n18mr13750879otk.294.1615060573829;
Sat, 06 Mar 2021 11:56:13 -0800 (PST)
MIME-Version: 1.0
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Sat, 6 Mar 2021 19:56:02 +0000
Message-ID: <CAFvNmHQKrw=UsUqNfBy2pO-LyfH=7VwO8z1VaHPvimXGReUyBQ@mail.gmail.com>
To: Dave Harding <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cb3e9005bce397b1"
X-Mailman-Approved-At: Sat, 06 Mar 2021 20:39:29 +0000
Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
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: Sat, 06 Mar 2021 19:56:16 -0000
--000000000000cb3e9005bce397b1
Content-Type: text/plain; charset="UTF-8"
Hi Matt
> I'm really unsure that three months is a short enough time window that
there wouldn't be a material effort to split the network with divergent
consensus rules. Instead, a three month window is certainly long enough to
organize and make a lot of noise around such an effort, given BIP 148 was
organized and reached its peak within a similar such window.
I'm not sure either. I can't control anyone other than myself. I think (and
Luke has also stated on IRC) that trying a UASF (LOT=true) during a "Speedy
Trial" deployment would be crazy. I would certainly recommend no one tries
that but I can't stop anyone. I'll repeat that soft forks have and always
will contain some limited chain split risk regardless of activation
mechanism. I think you are well intentioned but I'm not sure if you've
fully grasped that yet. Maybe you have and I'm missing something.
> Worse, because the obvious alternative after a three month activation
failure is a significant delay prior to activation, the vocal UASF minority
may be encouraged to pursue such a route to avoid such a delay.
Again I can only speak for myself but I wouldn't support a UASF until this
"fail fast" Speedy Trial has completed and failed. Luke agrees with that
and other people (eg proofofkeags) on the ##uasf IRC channel have also
supported this "Speedy Trial" proposal. If you want me (or anyone else for
that matter) to guarantee there won't be an attempted UASF during a Speedy
Trial deployment obviously nobody can do that. All I can say is that
personally I won't support one.
> One alternative may be to reduce the signaling windows involved and start
slightly later. Instead of the likelihood of failure growing on the
horizon, simply have two signaling windows (maybe two weeks, maybe a moth
each?). In order to ensure success remains likely, begin them somewhat
later after software release to give pools and miners a chance to configure
their mining software in advance.
The parameters for Speedy Trial are being hammered out on IRC as we speak.
I'd encourage you to engage with those discussions. I'd really like to
avoid a scenario where we have broad consensus on the details of Speedy
Trial and then you come out the woodwork weeks later with either an
alternative proposal or a criticism for how the details of Speedy Trial
were finalized.
I've read your email as you're concerned about a UASF during a Speedy Trial
deployment. Other than that I think (?) you support it and you are free to
join the discussion on IRC if you have particular views on parameters.
Personally I don't think those parameters should be chosen assuming there
will be a UASF during the deployment but you can argue that case on IRC if
you wish. All proposals you have personally put forward suffer from chain
split risk in the face of a competing incompatible activation mechanism.
--
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--000000000000cb3e9005bce397b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Matt</div><div><br></div><div>> I'm really =
unsure that three months is a short enough time window that there wouldn=
9;t be a material effort to split the network with divergent consensus rule=
s. Instead, a three month window is certainly long enough to organize and m=
ake a lot of noise around such an effort, given BIP 148 was organized and r=
eached its peak within a similar such window.<br></div><div><br></div><div>=
I'm not sure either. I can't control anyone other than myself. I th=
ink (and Luke has also stated on IRC) that trying a UASF (LOT=3Dtrue) durin=
g a "Speedy Trial" deployment would be crazy. I would certainly r=
ecommend no one tries that but I can't stop anyone. I'll repeat tha=
t soft forks have and always will contain some limited chain split risk reg=
ardless of activation mechanism. I think you are well intentioned but I'=
;m not sure if you've fully grasped that yet. Maybe you have and I'=
m missing something.<br><div><br></div><div><div>> Worse, because the ob=
vious alternative after a three month activation failure is a significant d=
elay prior to activation, the vocal UASF minority may be encouraged to purs=
ue such a route to avoid such a delay.</div><div><br></div><div>Again I can=
only speak for myself but I wouldn't support a UASF until this "f=
ail fast" Speedy Trial has completed and failed. Luke agrees with that=
and other people (eg proofofkeags) on the ##uasf IRC channel have also sup=
ported this "Speedy Trial" proposal. If you want me (or anyone el=
se for that matter) to guarantee there won't be an attempted UASF durin=
g a Speedy Trial deployment obviously nobody can do that. All I can say is =
that personally I won't support one.</div><div><br>> One alternative=
may be to reduce the signaling windows involved and start slightly later. =
Instead of the likelihood of failure growing on the horizon, simply have tw=
o signaling windows (maybe two weeks, maybe a moth each?). In order to ensu=
re success remains likely, begin them somewhat later after software release=
to give pools and miners a chance to configure their mining software in ad=
vance.</div><div><br></div><div>The parameters for Speedy Trial are being h=
ammered out on IRC as we speak. I'd encourage you to engage with those =
discussions. I'd really like to avoid a scenario where we have broad co=
nsensus on the details of Speedy Trial and then you come out the woodwork w=
eeks later with either an alternative proposal or a criticism for how the d=
etails of Speedy Trial were finalized.=C2=A0</div><div><br></div><div>I'=
;ve read your email as you're concerned about a UASF during a Speedy Tr=
ial deployment. Other than that I think (?) you support it and you are free=
to join the discussion on IRC if you have particular views on parameters. =
Personally I don't think those parameters should be chosen assuming the=
re will be a UASF during the deployment but you can argue that case on IRC =
if you wish. All proposals you have personally put forward suffer from chai=
n split risk in the face of a competing incompatible activation mechanism.<=
/div><div><br></div><div><br>-- <br>Michael Folkson<br>Email: <a href=3D"ma=
ilto:michaelfolkson@gmail.com">michaelfolkson@gmail.com</a><br>Keybase: mic=
haelfolkson<br>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</div>=
</div></div></div>
--000000000000cb3e9005bce397b1--
|
