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
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0C54BC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Apr 2022 02:36:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id E577F400E5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Apr 2022 02:36:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, 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: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.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 2TTG9gmAgR_e
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Apr 2022 02:36:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
[IPv6:2a00:1450:4864:20::635])
by smtp2.osuosl.org (Postfix) with ESMTPS id 7DFEF400D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Apr 2022 02:36:07 +0000 (UTC)
Received: by mail-ej1-x635.google.com with SMTP id kq17so677367ejb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Apr 2022 19:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=sCd5waZnW0J0pS+hwWvQpS0qFUBqfGwPrCXJQymU7tE=;
b=kPnPYkcGM9bL3I+d0tPV6Roo1Gi+JsqH6tGxWVsFhGn8Hzk790m7bdhepLupGf1FPg
UTJEG+TSyDlzNYJ8VVvra0gAAk7hQZIeBK6hzYKEB2jVity+HhAI0oF+tKZ6EcJfKzcd
+iVhhuMmLFTIRx1z74pfHLDBcv+L617KIQh5SfLRPtMH57ZSCmxu/H0zIykcObTSzpfb
ZyoFIfSweQRBw7XtC9ZRebcOpLTZ8mNISt/XE34KZx1O78Y+X/Fnrlc6aFLKGm7b7/Xs
uZnkWzTfbyMAJRDjmuwvBdT51qWfi010NtnI2r41Av3nSYSxv07n4ws0puhKzfxictSG
DxcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=sCd5waZnW0J0pS+hwWvQpS0qFUBqfGwPrCXJQymU7tE=;
b=zAj9hX2fgZM/newJkafvVRRYH0iKg0k0wD8h+FbjKe5kEjCEZ/XW6S3BnxXu9vS+Tk
rFIndItC/xQa3D37euRpzZgcqFoXi3xJwmTGPgJUSVtKtVDvJYdJAp/PbQ8cB3S28Nas
ul6s8uBMf/kNHWAnjeCVsF61uBvpwJBprvXPUhkBMCmsZqJTVyGpv63fwqrZG7wq+OKb
03nIcXWbxUf+Hp2MRAzqcFxbMVM1o5KX6VpZeO/suLorqUhX8a3kIKYcF/e9y3XDEvbx
ioRpD6BxXiY1KRxANHnJsizBI53eaNl3JvV4K1fqWUiYQ53HFcwo7K5B6dLX1GZM6yHm
l9kA==
X-Gm-Message-State: AOAM532fgEbrH+fq4sNisHnZK3+DF6j5sklR0MZnoWaBfesXKFtQSmjj
aCAvJ1aOYH0cEJmXwOfX4w+78lqT4rDC2HqOO49lfMgAoj0=
X-Google-Smtp-Source: ABdhPJwLu9AH211YG5K9B5ECQ/UUzfEwy9cpcDX9BXpByBywcLGLlocm9W5WA25WYb+jGkfku+J/X5DZWWWrXL6S8y4=
X-Received: by 2002:a17:907:a42a:b0:6f3:c500:5f50 with SMTP id
sg42-20020a170907a42a00b006f3c5005f50mr1053873ejc.281.1651026965560; Tue, 26
Apr 2022 19:36:05 -0700 (PDT)
MIME-Version: 1.0
References: <CABm2gDpMxN0sBCpcbmvYsQbdsGp=JRjAyLhsd6BWyAxdCY95+A@mail.gmail.com>
<20220330042106.GA13161@erisian.com.au>
<CABm2gDrsZ9ZimFTkNrdj+wr7328h2N2GmRCawq8xYv3BqyHNow@mail.gmail.com>
<20220411130522.GA3633@erisian.com.au>
<CABm2gDqw7ZSLwuFvWstLpkRAFT_4DLWkhNFBLW8m_E46_VWG3A@mail.gmail.com>
<20220424121429.GA7363@erisian.com.au>
<CABm2gDo0=psMAKY6Pvfp8b-RvAJdUabiESJpff_yzgwmy7cigQ@mail.gmail.com>
<CALeFGL19G7eLdM7J9dQrumdVTgo1OyoK6UbzF3oJMkGG55qLzg@mail.gmail.com>
<20220425170012.GA7453@erisian.com.au>
<CALeFGL3Ga+jqGDf0zGVev7RMYnZQVQaRQ7SXxsY=qH+CGhoPpg@mail.gmail.com>
<20220426054214.GA7933@erisian.com.au>
<CAJowKg+HM6Z44rOVrS0_g=GdzWPZVwggxgQYGPTBrZDir5W4Hw@mail.gmail.com>
In-Reply-To: <CAJowKg+HM6Z44rOVrS0_g=GdzWPZVwggxgQYGPTBrZDir5W4Hw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 26 Apr 2022 21:35:49 -0500
Message-ID: <CAGpPWDY0H2d8wMyY+X1fFOtn0aKLi_+2BT8AoDS0+Yae+-8EEg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cc003605dd99ab6c"
X-Mailman-Approved-At: Wed, 27 Apr 2022 08:09:15 +0000
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [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: Wed, 27 Apr 2022 02:36:09 -0000
--000000000000cc003605dd99ab6c
Content-Type: text/plain; charset="UTF-8"
@Erik
> can we all agree that this verbal and social wrangling and chest
pounding seems, right now, to remain the best system of achieving
consensus? or can we do better?
I would love to see more people interested in discussing this. Social
wrangling is certainly the best we have, but is it the best we can do?
Certainly a certain amount of discussion and back and forth is necessary to
come to consensus, but it would be nice to have a discussion and come to a
consensus on things like the minimum things required to decided consensus
is for something (the absence of which makes it obvious that consensus is
currently against), and the maximum amount of things required after which
it would be clear and obvious that consensus for something has been
achieved.
> wallet votes (sign a message signalling... ), can cause centralization
pressures
I'm curious to know why you think this is the case. If you mean that
centralization of custody is a problem for this, I very much agree.
However, I don't see how having wallet votes would incentivize
centralization of custody. Rather the opposite actually - one more reason
to self-custody.
Regardless, I wouldn't suggest having wallet *votes* per se. I would doubt
we'd get a high enough response rate on that to really determine what
broader consensus of coin-owners is. However, if we had coin-weighted
polling, it would I think be a very useful signal by which we could
determine something (to some degree of uncertainty) about what consensus is
among that group (of coin owners who take the poll).
Theoretically, the economic majority of bitcoin holders can direct the
majority of mining power, and can control where the current chain goes (of
course not discounting the ability of the economic minority to hard fork
away if they want, taking a proportional minority amount of mining power
with them).
One could also think of it like Polybius's three part government, where the
parts in bitcoin would be: developers, miners, and holders. Perhaps a
consensus among all of them should be ideally sought after for a smooth
upgrade. Because of the blocksize wars, many think miners should simply act
as a machine to implement the will of the bitcoiners. However, I think
people sometimes forget that miners are also bitcoiners and they have a
unique and important perspective. If the opinions and interests of miners
is already adequately considered as part of our chaotic discussions on what
consensus is, then great. If not, it would seem that the miner signaling
process is a reasonable place for miners to decide to delay and force more
discussion. While its unlikely the average user knows much about the
technical aspects of consensus changes, the fact is that there are many
non-developer stakeholders, and it would I think be a very beneficial
achievement to figure out a way to incorporate those stakeholders into the
process of determining consensus on the most important changes to bitcoin:
consensus changes.
On Tue, Apr 26, 2022 at 11:32 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> - it occurs to me that the real problem we have isn't whether miners lead
> or users lead. we know that users lead, we just need miners to be "ready"
> and have time to upgrade their software
>
> - in the case of "evil" forks, i also don't need or want miners to
> "defend" bitcoin... (if bitcoin is so broken that a bad fork gets past all
> of the users, the miners have lost their purpose, so that is a fallacy of
> reification and should be ignored)
>
> - we cannot measure user consensus in any systematic way, or else we
> resort to gaming the system or centralization
>
> - wallet votes (sign a message signalling... ), can cause
> centralization pressures
> - node signals (node published signal) will be sybil attacked
> - eyeballs... (lol)
>
> - can we all agree that this verbal and social wrangling and chest
> pounding seems, right now, to remain the best system of achieving
> consensus? or can we do better?
>
>
>
>
>
>
>
>
>
>
> On Tue, Apr 26, 2022 at 1:42 AM Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via
>> bitcoin-dev wrote:
>> > > Semi-mandatory in that only "threshold" blocks must signal, so if
>> > only 4% or 9% of miners aren't signalling and the threshold is set
>> > at 95% or 90%, no blocks will be orphaned.
>> > How do nodes decide on which blocks are orphaned if only some of them
>> have
>> > to signal, and others don't? Is it just any block that would cause the
>> > whole threshold period to fail?
>>
>> Yes, exactly those. See [0] or [1].
>>
>> [0]
>> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling
>>
>> [1] https://github.com/bitcoin/bips/pull/1021
>> (err, you apparently acked that PR)
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000cc003605dd99ab6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>@Erik</div>>=C2=A0
can we all agree that this verbal and social wrangling and chest pounding s=
eems, right now, to remain the best system of achieving consensus?=C2=A0 or=
can we do better?<div><br></div><div>I would love to see more people inter=
ested in discussing this. Social wrangling is certainly the best we have, b=
ut is it the best we can do? Certainly a certain amount of discussion and b=
ack and forth is necessary to come to consensus, but it would be nice to ha=
ve a discussion and come to a consensus on things like the minimum things r=
equired to decided consensus is for something (the absence=C2=A0of which ma=
kes it obvious that consensus is currently against), and the maximum amount=
of things required after which it would be clear and obvious that consensu=
s for something has been achieved.=C2=A0<br></div><div><br></div><div>> =
wallet votes (sign a message signalling... ), can cause centralization pres=
sures</div><div><br></div><div>I'm curious to know why you think this i=
s the case. If you mean that centralization of custody is a problem for thi=
s, I very much agree. However, I don't see how having wallet votes woul=
d incentivize centralization of custody. Rather the opposite actually - one=
more reason to self-custody.</div><div><br></div><div>Regardless, I wouldn=
't suggest having wallet *votes* per se. I would doubt we'd get a h=
igh enough response rate on that to really determine what broader consensus=
of coin-owners is. However, if we had coin-weighted polling, it would I th=
ink be a very useful signal by which we could determine something (to some =
degree of uncertainty) about what consensus is among that group (of coin ow=
ners who take the poll).=C2=A0</div><div><br></div><div>Theoretically, the =
economic majority of bitcoin holders can direct the majority of mining powe=
r, and can control where the current chain goes (of course not discounting =
the ability of the economic minority to hard fork away if they want, taking=
a proportional minority amount of mining power with them).</div><div><br><=
/div><div>One could also think of it like Polybius's three part governm=
ent, where the parts in bitcoin would be: developers, miners, and holders. =
Perhaps a consensus among all of them should be ideally sought after for a =
smooth upgrade. Because of the blocksize wars, many think miners should sim=
ply act as a machine to implement the will of the bitcoiners. However, I th=
ink people sometimes forget that miners are also bitcoiners and they have a=
unique and important perspective. If the opinions and interests of miners =
is already adequately considered as part of our chaotic discussions on what=
consensus is, then great. If not, it would seem that the miner signaling p=
rocess is a reasonable place for miners to decide to delay and force more d=
iscussion. While its unlikely the average user knows much about the technic=
al aspects of consensus changes, the fact is that there are many non-develo=
per stakeholders, and it would I think be a very beneficial achievement to =
figure out a way to incorporate those stakeholders into the process of dete=
rmining consensus on the most important changes to bitcoin: consensus chang=
es.=C2=A0</div><div><br></div><div><br></div></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 26, 2022 at 11:32 =
AM Erik Aronesty via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">- =
it occurs to me that the real problem we have isn't whether miners lead=
or users lead.=C2=A0 =C2=A0we know that users lead, we just need miners to=
be "ready" and have time to upgrade their software<div><br></div=
><div>=C2=A0- in the case of "evil" forks, i also don't need =
or want miners to "defend" bitcoin... (if bitcoin is so broken th=
at a bad fork gets past all of the users, the miners have lost their purpos=
e, so that is a fallacy of reification and should be ignored)<br><br>=C2=A0=
- we cannot measure user consensus in any systematic way, or else we resort=
to gaming the system or centralization=C2=A0</div><div><br></div><div>=C2=
=A0 =C2=A0 - wallet votes (sign a message signalling... ), can cause centra=
lization pressures</div><div>=C2=A0 =C2=A0 - node signals (node published s=
ignal) will be sybil attacked</div><div>=C2=A0 =C2=A0 - eyeballs... (lol)</=
div><div><br></div><div>=C2=A0- can we all agree that this verbal and socia=
l wrangling and chest pounding seems, right now, to remain the best system =
of achieving consensus?=C2=A0 or can we do better?</div><div><br></div><div=
><br></div><div><br><br><br></div><div><br></div><div><br></div><div><br></=
div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Tue, Apr 26, 2022 at 1:42 AM Anthony Towns via bitcoi=
n-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Apr 25, 2022 at 11=
:26:09AM -0600, Keagan McClelland via bitcoin-dev wrote:<br>
> > Semi-mandatory in that only "threshold" blocks must sig=
nal, so if<br>
>=C2=A0 =C2=A0 =C2=A0only 4% or 9% of miners aren't signalling and t=
he threshold is set<br>
>=C2=A0 =C2=A0 =C2=A0at 95% or 90%, no blocks will be orphaned.<br>
> How do nodes decide on which blocks are orphaned if only some of them =
have<br>
> to signal, and others don't? Is it just any block that would cause=
the<br>
> whole threshold period to fail?<br>
<br>
Yes, exactly those. See [0] or [1].<br>
<br>
[0] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0008.mediawi=
ki#Mandatory_signalling" rel=3D"noreferrer" target=3D"_blank">https://githu=
b.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling</a><=
br>
<br>
[1] <a href=3D"https://github.com/bitcoin/bips/pull/1021" rel=3D"noreferrer=
" target=3D"_blank">https://github.com/bitcoin/bips/pull/1021</a><br>
=C2=A0 =C2=A0 (err, you apparently acked that PR)<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000cc003605dd99ab6c--
|