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
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4A55AC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Mar 2022 00:12:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 31C2C40556
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Mar 2022 00:12:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
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: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id FrU4F1dKuPsD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Mar 2022 00:12:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com
[IPv6:2607:f8b0:4864:20::72e])
by smtp2.osuosl.org (Postfix) with ESMTPS id D77A04014E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Mar 2022 00:12:31 +0000 (UTC)
Received: by mail-qk1-x72e.google.com with SMTP id q4so5814625qki.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2022 16:12:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:from:date:message-id:subject:to;
bh=UVCxasCsBI6hwWd7PFfDFdLogCUYpt99zpVPlVzvra4=;
b=M30tzsoXz2DdGGXsIiYQreldyyID4GNy9p1MklMD1gVvtfz78SwIKkKHrnV620VZWl
auHqrEM1yQR6kGCZgYK6IWuve4pcnZXSr6+etjlWn90hN1OkCEs/+gHylDk0PP3VRkvQ
stsxCOT/HiZPUoKagBEF1JiysELyW9jEBjra2WSLLHIWv4WTDsb3VSt6XPTRxJha2BrS
2r4BdVKA0h/XUkW9gudl+tyv+MqE8OUxhPCKVwrWMVTskb+++fzOy5c6IbBzVF3T0eHs
j6K1Z9AXlzQDqk6+joiWZS377DRKFwUXneTN7Yx5kDKufgXRc9ov81vYZtjjsQYnriuM
V3kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=UVCxasCsBI6hwWd7PFfDFdLogCUYpt99zpVPlVzvra4=;
b=BDEZaMtnMRSgelmKapX+FsX/oVaDwQSWmrgTsNZIfymDJdYjMeidsTvfCXnlnURzWH
renNpI+RLKWDbHqQVu4iK+ilciG1eLhnUOv/SlDBxXgzywiLpUj9Jk8TfA29wohWez5u
5Kqv8fhwqqua6gZ6oUB3Vn+oJSImGBRC+6IsKaCpfYo1Ecm5cZmtJGV2WY4KK1FJTI2f
Ea8UC4i4c1u350l8NPdSNLDfSupfbUdFAVvITv0hCgIThMXC/nKrJnyXk5OxJJZoDl8w
Z7fMeZPU5QQlTRXfxrpMO2Wv8LmGRPnZK/c8u/6RnwlsDNcfaPCBgzX03tnL5eKHdigx
nhug==
X-Gm-Message-State: AOAM533I1ZuGxCfn1Smi4Mb7eR2ccm7lZCy3DOWbQda+LZaIBpHpRIkh
cbAug46xJ3uJL0XMxqR7vErM5r2eHrxuU86j0K3u85oZSFB6ZQ==
X-Google-Smtp-Source: ABdhPJwk4zySLwUxrBEKLX8Z4CdVEvmkbu0l7q7U5+g+2QA4Bi/0a+BGGo/yaMAfCXH5ge2BWh9pCHbJzKti9hzphWQ=
X-Received: by 2002:a05:620a:2082:b0:67b:1235:2ff2 with SMTP id
e2-20020a05620a208200b0067b12352ff2mr4872990qka.640.1646957550352; Thu, 10
Mar 2022 16:12:30 -0800 (PST)
MIME-Version: 1.0
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Thu, 10 Mar 2022 19:12:19 -0500
Message-ID: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bfd17a05d9e62ffc"
Subject: [bitcoin-dev] 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: Fri, 11 Mar 2022 00:12:33 -0000
--000000000000bfd17a05d9e62ffc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu., Mar. 10, 2022, 08:04 Jorge Tim=C3=B3n via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> You're right, we shouldn't get personal. We shouldn't ignore feedback fro=
m
> me, mark friedenbach or luke just because of who it comes from.
>
For goodness sake Jorge, enough with the persecution complex.
As the person who initially proposed the Speedy Trial deployment design, I
can say it was designed to take in account those concerns raised by luke-jr
and the "no-miner-veto" faction. I also listened to the
"devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction
and their concerns.
The "no-miner-veto" concerns are, to an extent, addressed by the short
timeline of Speedy Trial. No more waiting 2 years on the miners dragging
their feet. If ST fails to active then we are back where we started with
at most a few weeks lost. And those weeks aren't really lost if they would
have been wasted away anyways trying to find broad consensus on another
deployment mechanism.
I get that you don't like the design of Speedy Trial. You may even object
that it fails to really address your concerns by leaving open how to follow
up a failed Speedy Trial deployment. But regardless of how you feel, I
believe I did meaningfully address the those miner-veto concerns and other
people agree with me.
If you are so concerned about listening to legitimate criticism, maybe you
can design a new deployment mechanism that addresses the concerns of the
"devs-do-not-decide" faction and the "no-divegent-consensus-rules"
faction. Or do you feel that their concerns are illegitimate? Maybe, by
sheer coincidence, all people you disagree with have illegitimate concerns
while only your concerns are legitimate.
A major contender to the Speedy Trial design at the time was to mandate
eventual forced signalling, championed by luke-jr. It turns out that, at
the time of that proposal, a large amount of hash power simply did not have
the firmware required to support signalling. That activation proposal
never got broad consensus, and rightly so, because in retrospect we see
that the design might have risked knocking a significant fraction of mining
power offline if it had been deployed. Imagine if the firmware couldn't be
quickly updated or imagine if the problem had been hardware related.
--000000000000bfd17a05d9e62ffc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"l=
tr" class=3D"gmail_attr">On Thu., Mar. 10, 2022, 08:04 Jorge Tim=C3=B3n via=
bitcoin-dev, <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer no=
referrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">=
<div><div class=3D"gmail_quote"><br></div></div><div dir=3D"auto"><br></div=
><div dir=3D"auto">You're right, we shouldn't get personal. We shou=
ldn't ignore feedback from me, mark friedenbach or luke just because of=
who it comes from.</div></div></blockquote></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">For goodness sake Jorge, enough with the persecution c=
omplex.</div><div dir=3D"auto"><br></div><div dir=3D"auto">As the person wh=
o initially proposed the Speedy Trial deployment design, I can say it was d=
esigned to take in account those concerns raised by luke-jr and the "n=
o-miner-veto" faction.=C2=A0 I also listened to the "devs-do-not-=
decide" faction and the "no-divegent-consensus-rules" factio=
n and their concerns.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Th=
e "no-miner-veto" concerns are, to an extent, addressed by the sh=
ort timeline of Speedy Trial.=C2=A0 No more waiting 2 years on the miners d=
ragging their feet.=C2=A0 If ST fails to active then we are back where we s=
tarted with at most a few weeks lost.=C2=A0 And those weeks aren't real=
ly lost if they would have been wasted away anyways trying to find broad co=
nsensus on another deployment mechanism.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">I get that you don't like the design of Speedy Trial.=
=C2=A0 You may even object that it fails to really address your concerns by=
leaving open how to follow up a failed Speedy Trial deployment.=C2=A0 But =
regardless of how you feel, I believe I did meaningfully address the those =
miner-veto concerns and other people agree with me.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">If you are so concerned about listening to legi=
timate criticism, maybe you can design a new deployment mechanism that addr=
esses the concerns of the "devs-do-not-decide" faction and the &q=
uot;no-divegent-consensus-rules" faction.=C2=A0 Or do you feel that th=
eir concerns are illegitimate?=C2=A0 Maybe, by sheer coincidence, all peopl=
e you disagree with have illegitimate concerns while only your concerns are=
legitimate.</div><div dir=3D"auto"><br></div><div dir=3D"auto">A major con=
tender to the Speedy Trial design at the time was to mandate eventual force=
d signalling, championed by luke-jr.=C2=A0 It turns out that, at the time o=
f that proposal, a large amount of hash power simply did not have the firmw=
are required to support signalling.=C2=A0 That activation proposal never go=
t broad consensus, and rightly so, because in retrospect we see that the de=
sign might have risked knocking a significant fraction of mining power offl=
ine if it had been deployed.=C2=A0 Imagine if the firmware couldn't be =
quickly updated or imagine if the problem had been hardware related.</div><=
div dir=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"></div></=
div>
--000000000000bfd17a05d9e62ffc--
|
