summaryrefslogtreecommitdiff
path: root/6a/8eea6e8372aee3c491333e37fb15e5f192f7ec
blob: 31efeef99ab8c6231df8223fd0a05bc0e001368f (plain)
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
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
Return-Path: <eric@voskuil.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C7A3EC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 08:55:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B5F9040137
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 08:55:49 +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]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.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 qcBlQ2bzu8o2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 08:55:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [IPv6:2607:f8b0:4864:20::62c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3E1A6402E3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 08:55:48 +0000 (UTC)
Received: by mail-pl1-x62c.google.com with SMTP id z4so1071859plg.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 01:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=from:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:thread-index:content-language;
 bh=2Xtfy5GqrUdbqxW0mbGyXnKsULjlR7fDR43OVxiEI4U=;
 b=UBCp7d9wSr/Osgi1ArA3g0RmQW+B3GsTPkQtZigBoxNaie+wnsK3ZbsKyLgL4E9+BY
 KQ6TBDyL2p/ECskt7VEq0V7xgfE9vZaSQL0pFdTJdTPWavVUHZp2bioUhYg6FW9dghc1
 JdRdPnBNeZ8+gnxQ9b/JQ+Fb8yEAlUamG/ONiwI3+H+P+FN38ByO9fyYeC52xF5bFGbX
 zmQHSwBeJ8PqtsM+NLR84VaZ27DOKc+eZK7Hv1rbIC6JzDLZlDbkvAtXupv8drwsevT9
 R5WCP12te7wV3oQPePCsHGeWtQIpUtsDz36pGtKycdEaxuQgvD5i2Yd+7i89WlU6ImXS
 Aa8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date
 :message-id:mime-version:thread-index:content-language;
 bh=2Xtfy5GqrUdbqxW0mbGyXnKsULjlR7fDR43OVxiEI4U=;
 b=RV6WH/0+xA0nXLSnTik/5sphmkAPivAnDofTqa2cyOIpqd01oRpaBcFa6JTf+pXpvr
 +ZVyIredoBy34Fndwto9T8AyBLgBJFup1q3Y4QQvnTFfSTVnnMDJLuszLBibhELCFwfv
 zqbn2RLh9z5EE8TQ2O9AcLDao0ZFcXTp2pHMS0OWZR9bT1YoWYAVxFu9sQsjAlZ5TleR
 zNniIuvA3boeDxcCdDIGRkaaRphaZTBZjoMQyQVsXp+AlBL9ofj1QM5StFQejB5/VS/J
 DtHjWWuVxDDsyxvJOaubucaskJ9EJriRZQFLXyWY3Dr+fo0tzrPITaLRKn9WaYmKg29w
 +hTA==
X-Gm-Message-State: AOAM531JRsZWgbS2inIUSj++ZZgI+16D+8qwUwdeZqfGCPb16jekRRMW
 DZ6SC0ZR6Q/B1uyzfmL3+rTm/Q==
X-Google-Smtp-Source: ABdhPJzLMJZs4Whij513I3restW3i/S3b51HX+3QdQBW0Ork8m9IlVByLH0nyC4FfZ1yXw2hTKQk6Q==
X-Received: by 2002:a17:90a:df10:: with SMTP id
 gp16mr3433056pjb.164.1625043347614; 
 Wed, 30 Jun 2021 01:55:47 -0700 (PDT)
Received: from ERICDESKTOP ([2601:600:9c00:1d0::9d25])
 by smtp.gmail.com with ESMTPSA id z26sm17131623pfk.112.2021.06.30.01.55.46
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 30 Jun 2021 01:55:47 -0700 (PDT)
From: <eric@voskuil.org>
To: "'Billy Tetrud'" <billy.tetrud@gmail.com>
References: <CABm2gDot=YnMB8isbouLV_g=P=OAeN7H966juqbBexXyK9jw8A@mail.gmail.com>
 <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org>
 <CAGpPWDZVak_8pbfOE7SXNWy31_5LmabY4xj8pseUzR7XMJX5ug@mail.gmail.com>
In-Reply-To: <CAGpPWDZVak_8pbfOE7SXNWy31_5LmabY4xj8pseUzR7XMJX5ug@mail.gmail.com>
Date: Wed, 30 Jun 2021 01:55:47 -0700
Message-ID: <020101d76d8d$b86397f0$292ac7d0$@voskuil.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_0202_01D76D53.0C05F870"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGzRHqRlNUnlmfFxKP28gVDQPjFFgHW7TzYAa1DJcarWGSOAA==
Content-Language: en-us
Cc: 'Bitcoin Protocol Discussion' <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
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, 30 Jun 2021 08:55:49 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0202_01D76D53.0C05F870
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All good questions.

=20

> Is the goal here to do what the economic majority wants, or some other =
group? If so, do you think we have an accurate way of measuring what the =
economic majority wants?

=20

It=E2=80=99s important that people understand that =
=E2=80=9Ceconomic=E2=80=9D does not refer to people interested in, =
HODLing, coding, or selling Bitcoin. It is only those who are *presently =
accepting* it. We refer to these as =E2=80=9Ceconomic nodes=E2=80=9D. =
Those are the people with the economic power to reject coin that they =
consider invalid. Only their validation is of any economic consequence =
in the event of a split. I see no reason to assume that the economy is =
any less centralized than mining is pooled. Today the support of the =
economy would be best measured by meeting with exchange operators. If =
they did not go along, any unenforced soft fork (split) would isolate =
everyone who thought they could continue to trade their coin on =
exchanges.

=20

I=E2=80=99d also question the use of the term =
=E2=80=9Cmajority=E2=80=9D. It applies to hash power, by design, but not =
to the economy. A split of any size is possible, requiring no majority. =
All it requires is other people to trade with.

=20

Exchanges are highly regulated and compliant institutions. Mining =
operations are heavily pooled. Neither of these is inherently better =
than the other. Everyone can have a say by being a miner or being a =
merchant. Subeconomies can split, majority hash power can censor (which =
is the exact mechanism of soft fork enforcement). These ideas are =
straightforward and hardly worthy of debate. The interesting question is =
how one gets others to go along with his new coin. Make no mistake, any =
rule change (soft or hard) is a new coin. If hash power doesn=E2=80=99t =
enforce the new rules of a soft fork, the chain is split just as if it =
was a hard fork.

=20

I=E2=80=99m sure people will continue to try and devise ways to figure =
out who wants to come along, to try and convince people (including =
exchanges and miners) to do so, to reassure them that everyone else will =
=E2=80=9Chave to=E2=80=9D, and to mislead them about the actual behavior =
and risks. We=E2=80=99ve seen permanent splits, and we=E2=80=99ve seen =
hash power enforced soft forks. We=E2=80=99re likely to see more of =
both. But as core devs we have a responsibility to inform people, =
honestly, and let them decide. My only beef with this whole process has =
been that a widespread belief had formed, supported by far too many core =
devs (and even embedded in the text of deployed BIPs), that soft forks =
are inherently =E2=80=9Cbackward compatible=E2=80=9D. This is =
unequivocally not true. The only such compatibility is majority hash =
power enforcement of a soft fork. This is not a matter of opinion, =
it=E2=80=99s the core innovation of Bitcoin. Proof of Work settles the =
question of who has authority to order transactions. Majority hash power =
has that authority. Merchants can split again and again, but their =
miners will still have that authority. If one wants a say, one can mine.

=20

e

=20

From: Billy Tetrud <billy.tetrud@gmail.com>=20
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil <eric@voskuil.org>
Cc: Jorge Tim=C3=B3n <jtimon@jtimon.cc>; Luke Dashjr <luke@dashjr.org>; =
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork =
upgrades

=20

@Jorge

=20

>I don't think we should avoid splits at all costs.

=20

I absolutely agree that we shouldn't avoid splits at all costs. There =
are some costs too high to pay to avoid a split. If an economic majority =
started wanting to increase bitcoin's blocksize to 1 GB next year, we =
should absolutely hard fork away from that mess with a minority chain.=20

=20

>  I don't think we should avoid splits when possible,=20

=20

I want to see why exactly we disagree about avoiding chain splits "when =
possible". Are you really saying that we should just hard fork every =
time instead of soft fork? Should we even bother to get widespread buy =
in at all, or should we just release the software, hardfork away, and =
let anyone that wants to follow us follow us later? Are you not at all =
worried about the costs associated with an increased orphan rate and =
reorg rate? Are you not worried that an update might happen too fast and =
that a significant fraction of people that could have come along with us =
to the new update might be left behind because they didn't have time to =
evaluate the changed rules?

=20

Do you agree that, in a conversation about rule changes, some people =
want it their way no matter what and will hardfork to get the rules they =
want, and some people want it their way, but only if enough other people =
agree to follow those rules too? Some people might want a rule change, =
but aren't willing to follow, say, a 20% minority fork. Perhaps their =
personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people =
exist?=20

=20

If you do, then I don't understand why you disagree that we should avoid =
chain splits even "when possible". Maybe you could elaborate as to what =
you mean there.=20

=20

@Luke

=20

Are you in agreement with Jorge here that we should not even attempt to =
avoid chain splits?=20

=20

> The only alternative to a split in the problematic scenarios are 1) =
concede centralised miner control over the network, and 2) have =
inconsistent enforcement of rules by users who don't agree on what the =
correct rules are, again leading to centralised miner control over the =
network.

=20

There is not simply a binary "do or do not". There is also timing. =
Non-contentious changes can happen fast. Contentious changes need more =
time for discussion, preparation, or coordination, even if the eventual =
outcome is the same. Do you disagree that timing issues can be =
important, that delays can be useful and help to avoid chain splits? Do =
you agree that miners have a (large) incentive to follow the economic =
majority? Is the goal here to do what the economic majority wants, or =
some other group? If so, do you think we have an accurate way of =
measuring what the economic majority wants? Will that mechanism continue =
to be accurate into the future?=20

=20

I'm asking these questions to try and figure out why we disagree here.


------=_NextPart_000_0202_01D76D53.0C05F870
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple style=3D'word-wrap:break-word'><div =
class=3DWordSection1><p class=3DMsoNormal>All good =
questions.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>&gt; Is the goal here to&nbsp;do what the economic =
majority wants,&nbsp;or some other group? If so, do you think we have an =
accurate way of measuring what the economic majority =
wants?<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>It=E2=80=99s important that people understand that =
=E2=80=9Ceconomic=E2=80=9D does not refer to people interested in, =
HODLing, coding, or selling Bitcoin. It is only those who are =
*<b>presently accepting</b>* it. We refer to these as =E2=80=9Ceconomic =
nodes=E2=80=9D. Those are the people with the economic power to reject =
coin that they consider invalid. Only their validation is of any =
economic consequence in the event of a split. I see no reason to assume =
that the economy is any less centralized than mining is pooled. Today =
the support of the economy would be best measured by meeting with =
exchange operators. If they did not go along, any unenforced soft fork =
(split) would isolate everyone who thought they could continue to trade =
their coin on exchanges.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I=E2=80=99d =
also question the use of the term =E2=80=9Cmajority=E2=80=9D. It applies =
to hash power, by design, but not to the economy. A split of any size is =
possible, requiring no majority. All it requires is other people to =
trade with.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Exchanges are highly regulated and compliant =
institutions. Mining operations are heavily pooled. Neither of these is =
inherently better than the other. Everyone can have a say by being a =
miner or being a merchant. Subeconomies can split, majority hash power =
can censor (which is the exact mechanism of soft fork enforcement). =
These ideas are straightforward and hardly worthy of debate. The =
interesting question is how one gets others to go along with his new =
coin. Make no mistake, any rule change (soft or hard) is a new coin. If =
hash power doesn=E2=80=99t enforce the new rules of a soft fork, the =
chain is split just as if it was a hard fork.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I=E2=80=99m =
sure people will continue to try and devise ways to figure out who wants =
to come along, to try and convince people (including exchanges and =
miners) to do so, to reassure them that everyone else will =E2=80=9Chave =
to=E2=80=9D, and to mislead them about the actual behavior and risks. =
We=E2=80=99ve seen permanent splits, and we=E2=80=99ve seen hash power =
enforced soft forks. We=E2=80=99re likely to see more of both. But as =
core devs we have a responsibility to inform people, honestly, and let =
them decide. My only beef with this whole process has been that a =
widespread belief had formed, supported by far too many core devs (and =
even embedded in the text of deployed BIPs), that soft forks are =
inherently =E2=80=9Cbackward compatible=E2=80=9D. This is unequivocally =
not true. The only such compatibility is majority hash power enforcement =
of a soft fork. This is not a matter of opinion, it=E2=80=99s the core =
innovation of Bitcoin. Proof of Work settles the question of who has =
authority to order transactions. Majority hash power has that authority. =
Merchants can split again and again, but their miners will still have =
that authority. If one wants a say, one can mine.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>e<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div =
style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in'><p class=3DMsoNormal><b>From:</b> Billy Tetrud =
&lt;billy.tetrud@gmail.com&gt; <br><b>Sent:</b> Tuesday, June 29, 2021 =
7:03 PM<br><b>To:</b> Eric Voskuil =
&lt;eric@voskuil.org&gt;<br><b>Cc:</b> Jorge Tim=C3=B3n =
&lt;jtimon@jtimon.cc&gt;; Luke Dashjr &lt;luke@dashjr.org&gt;; Bitcoin =
Protocol Discussion =
&lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br><b>Subject:</b> Re: =
[bitcoin-dev] Trinary Version Signaling for softfork =
upgrades<o:p></o:p></p></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p =
class=3DMsoNormal>@Jorge<o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>&gt;I don't think we should avoid splits at all =
costs.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I =
absolutely agree that we shouldn't avoid splits at all costs. There are =
some costs too high to pay to avoid a split. If an economic majority =
started wanting to increase bitcoin's blocksize&nbsp;to 1 GB next year, =
we should absolutely hard fork away from that mess with a minority =
chain.&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>&gt;&nbsp; I don't think we should avoid splits when =
possible,&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I =
want to see why exactly we disagree about avoiding chain splits =
&quot;when possible&quot;. Are you really saying that we should just =
hard fork every time instead of soft fork? Should we even bother to get =
widespread buy in at all, or should we just release the software, =
hardfork away, and let anyone that wants to follow us follow us later? =
Are you not at all worried about the costs associated with an increased =
orphan rate and reorg rate? Are you not worried that an update might =
happen too fast and that a significant fraction of people that could =
have come along with us to the new update might be left behind because =
they didn't have time to evaluate the =
changed&nbsp;rules?<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Do you agree that, in a conversation about rule =
changes, some people want it their way no matter what and will hardfork =
to get the rules they want, and some people want it their way, but only =
if enough other people agree to follow those rules too? Some people =
might want a rule change, but aren't willing to follow, say, a 20% =
minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or =
90%. Do you agree those people exist?&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>If you do, then I don't understand why you disagree =
that we should avoid chain splits even &quot;when possible&quot;. Maybe =
you could elaborate as to what you mean =
there.&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>@Luke<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Are you in agreement with Jorge here that we should =
not even attempt to avoid chain =
splits?&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>&gt; The only alternative to a split in the =
problematic scenarios are 1) concede centralised miner control over the =
network, and 2) have inconsistent enforcement of rules by users who =
don't agree on what the correct rules are, again leading to centralised =
miner control over the network.<o:p></o:p></p></div><div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>There is not simply a binary &quot;do or do not&quot;. =
There is also timing. Non-contentious changes can happen fast. =
Contentious changes need more time for discussion,&nbsp;preparation, or =
coordination,&nbsp;even if the eventual outcome is the same. Do you =
disagree that&nbsp;timing issues can be important,&nbsp;that&nbsp;delays =
can be useful and help to avoid chain&nbsp;splits? Do you agree that =
miners have a (large) incentive to follow the economic majority? Is the =
goal here to&nbsp;do what the economic majority wants,&nbsp;or some =
other group? If so, do you think we have an accurate way of measuring =
what the economic majority wants? Will that mechanism continue to be =
accurate into the future?&nbsp;<o:p></o:p></p></div></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>I'm asking these questions to try and figure out why =
we disagree here.<o:p></o:p></p></div></div></div></body></html>
------=_NextPart_000_0202_01D76D53.0C05F870--