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
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D36B2C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 18:12:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id B40D8402E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 18:12:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id JXvqnHtI2nYq
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 18:12:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
[IPv6:2a00:1450:4864:20::52b])
by smtp4.osuosl.org (Postfix) with ESMTPS id C945D402AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 18:12:05 +0000 (UTC)
Received: by mail-ed1-x52b.google.com with SMTP id t3so21840331edc.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 11:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=Rp/5PLn6/RQWiRpi5bW2UL4lT5L74zF4fcQRBnS1z1A=;
b=FBJHSySMOSaLQuiAj0jX44GG7z2+c9FqZ9QM7Pa+b1MIIahM+U+PFbILoTqdA8kNZq
MIywVX2bWsclKbeJ4tlDSGa4ZMA3XbqzBRkn8yQP9Jt8IBnTRQsMZqVvpRVamiVzhDAo
ObLDohpf845SCLmKhhrqYOZDf/1hEN4PyAL57L8zjgeGRyaHJB4MF7qflhiKMMuYYPYe
1aOBrwHve4ZLTg5Mt80PJJGUE8ArXz+98rzDPA9DBybJ4xetM3mh1osK6h7JBvo/3noj
03/clVb0wrgGlIgZme7HzzRZo+RxdFCNYV0DtZIG2F0/LzRrmHqayaKrqfy21O1Qmu1c
IlOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=Rp/5PLn6/RQWiRpi5bW2UL4lT5L74zF4fcQRBnS1z1A=;
b=OJPW4b2moiwdNItZOm0TU8UuxOmHIhcX2B6F6IkODaKJErXIwb/HIFKeGoRV4G08bo
WZux6g3Amvywf00j7lnqY4TAzXqwV9pCtckeQ6DDdWV2Pgn9otTuMntN5CgOcWruggod
qEFcz3GLf0w2COUOSFlWr5OWvZRdVV5dMNF5vNwFMtO0gM9cEccPzxiHyVejO4fqCnAs
Pjs44Ebh5UVDePvfXo6pR1DbMkhFemfCe4JmFca0PapysP9eCFQU1vM+LWORNB1JvEm5
wXaIT3BWCWm5zTsOjpbsQX22tAU6gHyWx7X2hdUWp6heib1uzXscxuKUG/hxPnvRWdg+
3hMw==
X-Gm-Message-State: AOAM5317phZeq1K7MUn5lo1Zoy03l2njRbyOmki0g97MxYZ++VM5XAVy
DMLtYdi9bmRacsMQwVByPhwqpdsF9ddTGYFtHbg=
X-Google-Smtp-Source: ABdhPJxth2PdpHgakYsox3uaTj67+6JqtoGXm+hQxF6+9c9+8E7D3Lx1anmvdo7bUMIGK3H1EqmJv0aMYluj0m7yUAQ=
X-Received: by 2002:a05:6402:1c1a:: with SMTP id
ck26mr27646177edb.230.1624817523813;
Sun, 27 Jun 2021 11:12:03 -0700 (PDT)
MIME-Version: 1.0
References: <CABm2gDrCOVN5FQ4DCGwG=1XjZisTVQdOKCwuPnNxd6yHQhy6rA@mail.gmail.com>
<E6D7F613-2378-44BE-8AFD-CB9A3CF59675@voskuil.org>
In-Reply-To: <E6D7F613-2378-44BE-8AFD-CB9A3CF59675@voskuil.org>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 27 Jun 2021 11:11:46 -0700
Message-ID: <CAGpPWDZKU7bM4URGxceoCmbvJNJBVhSsaiXTjie7kPoBh3TCkQ@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="00000000000054f23705c5c34f2e"
X-Mailman-Approved-At: Sun, 27 Jun 2021 19:24:54 +0000
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: Sun, 27 Jun 2021 18:12:08 -0000
--00000000000054f23705c5c34f2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
@Luke
> They can still slow it down.
Absolutely. However I think that the option of permanent failure is
important. It certainly would be ideal to ensure that enough bitcoin users
support the upgrade *before* releasing it, however realistically this can
never be more than an estimate, and estimates can sometimes be wildly
wrong. It would be unfortunate if miners had a substantially different
estimate of user support than the people putting in the work to release
bitcoin upgrades. Even if upgrades are never released before it becomes
clear that a large supermajority of users want the upgrade, if miners don't
agree with the estimate a harmful chain split could occur. And I agree with
Eric that the goal here is to prevent a chain split during an upgrade when
possible. This includes permanent failure of an upgrade when there is
unexpectedly large miner opposition.
This of course does not prevent a UASF-style deployment to be done after an
initial failure to deploy occurs. My proposal is essentially a mechanism to
improve upon the speedy-trial idea, allowing for even speedier releases
(than speedy trial) without adding additional risk of undesired chain
splits.
> [BIP8] already has the trinary state you seem to be describing
It sounds like you're saying the trinary state of BIP8 is A. Follow the
longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded
chain. I agree. However the trinary state in my proposal is materially
different - it is the signaling itself that is trinary, not just which
chain is being followed. This allows others to know and make programmatic
decisions (in software) based on that signaling. I'm sure you can agree
that does not exist in BIP8.
> No additional bit is needed, as softforks are coordinated between users,
NOT miners
And yet there is miner involvement, as you rightly pointed out. Miners are
needed to set the nVersion in the header. So when you say "no additional
bit is needed", could you please be clearer as to what you mean? Do you
mean that signaling of opposition in a block can be done without any
"additional bit"? Or are you just saying that it is redundant to consider
what miners might be opposing an upgrade?
@Jorge
> If different users want different incompatible things... there's no way
to avoid the split
I agree. This happened with bcash, and that's fine. It was painful, but
there were a significant amount of users that disagreed, and they have the
chain they want now.
But we generally all want to avoid a chain split when possible. Because
chain splits have a cost, and that cost can be high, its likely that many
users would rather choose the chain with the most support rather than
choosing the chain with their preferred rules.
However, the question here is: how do we estimate what fraction of users
wants which rules? We don't have a divining rod to determine with certainty
what users want. We can only make polls of various levels of inaccuracy.
The methods bitcoin has been using is community discussion and social
consensus estimation as well as miner signaling during the actual
deployment period. Neither of these are perfect, but they are both
reasonable enough mechanisms. However, because both of these mechanisms are
very rough estimates of user sentiment, we need to consider the possibility
that sometimes the estimate may be substantially inaccurate when we design
deployment procedures. This inaccuracy is why we need multiple barriers in
place for an upgrade, and why we need to have higher thresholds of success
(require larger supermajorities in both consensus and miner signaling).
Developers obviously care about bitcoin and have an incentive (personal and
probably financial) to do it right. And miners have both an incentive to
keep the system healthy, as well as an incentive to mine on the chain that
the economic majority of users is using. But measuring the consensus of the
bitcoin community can be extraordinarily difficult to do with consistent
accuracy, and so I think miner signaling as it has been used as a second
barrier to entry for an upgrade is quite appropriate.
On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric@voskuil.org> wrote:
> I have not objected to anyone splitting. As I said, a split is always
> possible, and of course has been done on a large scale. It is only the
> misleading statements about inherent soft fork =E2=80=9Ccompatibility=E2=
=80=9D and the
> implication that activation without hash power enforcement does not creat=
e
> a split that I object to. People who know better should be honest about i=
t.
>
> Far too many people have been led to believe there is some sort of
> activation choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe =
=E2=80=9Cslowed down=E2=80=9D).
> There is only a choice between creating a split and hash power enforcemen=
t.
> Soft forks are rule changes, and thereby incompatible - unless enforced b=
y
> majority hash power.
>
> The statements below are grossly misleading and need to be called out as
> such so that people can actually make this decision you speak of. This id=
ea
> that =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The qu=
estion is only how
> to avoid a split. If one does not care he can split at any time, no
> discussion required.
>
> e
>
> > On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> >
> > =EF=BB=BFIf different users want different incompatible things (enough =
on each
> > side), there's no way to avoid the split. We shouldn't try to avoid
> > such a split.
> > Users decide the rules, not miners nor developers.
> >
> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Ultimately there is only one answer to this question. Get majority has=
h
> power support.
> >>
> >> Soft fork enforcement is the same act as any other censorship
> enforcement, the difference is only a question of what people want. Given
> that there is no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bit=
coin resolves this
> question of conflicting wants, but it is not a democracy, it=E2=80=99s a =
market.
> One votes by trading.
> >>
> >> If one wants to enforce a soft fork (or otherwise censor) this is
> accomplished by mining (or paying others to do so). Anyone can mine, so
> everyone gets a say. Mining is trading capital now for more later. If
> enough people want to do that, they can enforce a soft fork. It=E2=80=99s=
time
> Bitcoiners stop thinking of miners as other people. Anyone can mine, and
> that=E2=80=99s your vote.
> >>
> >> Otherwise, as mentioned below, anyone can start a new coin. But it=E2=
=80=99s
> dishonest to imply that one can do this and all others will surely follow=
.
> This cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=99s one =
that has been
> shown to not always pay off.
> >>
> >> e
> >>
> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
> >>>
> >>> =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D.
> >>>
> >>> Without majority hash power support, activation simply means you are
> off on a chain split. Anyone can of course split off from a chain by
> changing a rule (soft or otherwise) at any time, so this is a bit of an
> empty claim.
> >>>
> >>> Nobody can stop a person from splitting. The relevant question is how
> to *prevent* a split. And activation without majority hash power certainl=
y
> does not =E2=80=9Censure=E2=80=9D this.
> >>>
> >>> e
> >>>
> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>>
> >>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrade=
entirely.
> They can
> >>>> still slow it down.
> >>>>
> >>>> It also already has the trinary state you seem to be describing
> (although
> >>>> perhaps this could be better documented in the BIP): users who oppos=
e
> the
> >>>> softfork can and should treat the successful signal (whether MASF or
> UASF) as
> >>>> invalid, thereby ensuring they do not follow a chain with the rules
> in force.
> >>>>
> >>>> No additional bit is needed, as softforks are coordinated between
> users, NOT
> >>>> miners (who have no particular say in them, aside from their role as
> also
> >>>> being users). The miner involvement is only out of necessity (to set
> the bit
> >>>> in the header, which users coordinate with) and potentially to
> accelerate
> >>>> activation by protecting upgrade-lagging users.
> >>>>
> >>>> Luke
> >>>>
> >>>>
> >>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
> wrote:
> >>>>> Given the recent controversy over upgrade mechanisms for the
> >>>>> non-controversial taproot upgrade, I have been thinking about ways
> to solve
> >>>>> the problems that both sides brought up. In short, BIP8 LOT=3Dtrue
> proponents
> >>>>> make the point that lazy miners failing to upgrade in a timely
> manner slow
> >>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3Dfalse
> >>>>> proponents make the point that LOT=3Dtrue can lead to undesirable
> forks that
> >>>>> might cause a lot of chaos. I believe both points are essentially
> correct
> >>>>> and have created a proposal
> >>>>> <
> https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/=
b
> >>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both
> problems.
> >>>>>
> >>>>> The proposal uses trinary version signaling rather than binary
> signaling.
> >>>>> For any particular prospective soft fork upgrade, this allows for
> three
> >>>>> signaling states:
> >>>>>
> >>>>> * Actively support the change.
> >>>>> * Actively oppose the change.
> >>>>> * Not signaling (neither support or oppose). This is the default
> state.
> >>>>>
> >>>>> Using this additional information, we can release non-contentious
> upgrades
> >>>>> much quicker (with a much lower percent of miners signaling
> support). For
> >>>>> contentious upgrades, miners who oppose the change are incentivized
> to
> >>>>> update their software to a version that can actively signal
> opposition to
> >>>>> the change. The more opposition there is, the higher the threshold
> >>>>> necessary to lock in the upgrade. With the parameters I currently
> >>>>> recommended in the proposal, this chart shows how much support
> signaling
> >>>>> would be necessary given a particular amount of active opposition
> >>>>> signaling:
> >>>>>
> >>>>> [image: thresholdChart.png]
> >>>>> If literally no one signals opposition, a 60% threshold should be
> >>>>> relatively safe because it is a supermajority amount that is
> unlikely to
> >>>>> change significantly very quickly (ie if 60% of miners support the
> change
> >>>>> today, its unlikely that less than a majority of miners would
> support the
> >>>>> change a year or two from now), and if no one is signaling
> opposition,
> >>>>> chances are that the vast majority of the other 40% would also
> eventually
> >>>>> signal support.
> >>>>>
> >>>>> This both gives an incentive for "lazy" miners to upgrade if they
> actually
> >>>>> oppose the change while at the same time allowing these lazy miners
> to
> >>>>> remain lazy without slowing down the soft fork activation much.
> >>>>>
> >>>>> I think now is the right time to discuss new soft fork upgrade
> mechanisms,
> >>>>> when there are no pressing soft fork upgrades ready to deploy.
> Waiting
> >>>>> until we need to deploy a soft fork to discuss this will only delay
> things
> >>>>> and cause contention again like it did with taproot.
> >>>>>
> >>>>> I'm very curious to know what people think of this mechanism. I wou=
ld
> >>>>> appreciate any comments here, or written as github issues on the
> proposal
> >>>>> repo itself.
> >>>>>
> >>>>> Thanks,
> >>>>> BT
> >>>>
> >>>> _______________________________________________
> >>>> 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
>
--00000000000054f23705c5c34f2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Luke<div>> They can still slow it down.</div><div><br>=
</div><div>Absolutely. However I think that the option of permanent failure=
is important. It certainly would be ideal to ensure that enough bitcoin us=
ers support the upgrade *before* releasing it, however realistically this c=
an never be more than an estimate, and estimates can sometimes be wildly wr=
ong. It would be unfortunate if miners had a substantially different estima=
te of user support than the people putting in the work to release bitcoin u=
pgrades. Even if upgrades are never released before it becomes clear that a=
large supermajority of users want the upgrade, if miners don't agree w=
ith the estimate a harmful chain split could occur. And I agree with Eric t=
hat the goal here is to prevent a chain split during an upgrade when possib=
le. This includes permanent=C2=A0failure of an upgrade when there is unexpe=
ctedly large miner opposition.=C2=A0</div><div><br></div><div>This of cours=
e does not prevent a UASF-style deployment to be done after an initial fail=
ure to deploy occurs. My proposal is essentially a mechanism to improve upo=
n the speedy-trial idea, allowing for even speedier releases (than speedy t=
rial) without adding additional risk of undesired chain splits.=C2=A0</div>=
<div><br></div><div>> [BIP8] already has the trinary state you seem to b=
e describing</div><div><br></div><div>It sounds like you're saying the =
trinary state of BIP8 is A. Follow the longest chain, B. Follow the upgrade=
chain, or C. follow the non-upgraded chain. I agree. However the trinary s=
tate in my proposal is materially different - it is the signaling itself th=
at is trinary, not just which chain is being followed. This allows others t=
o know and make programmatic decisions (in software) based on that signalin=
g. I'm sure you can agree that does not exist in BIP8.=C2=A0</div><div>=
<br></div><div>> No additional bit is needed, as softforks are coordinat=
ed between users, NOT miners</div><div><br></div><div>And yet there is mine=
r involvement, as you rightly pointed out. Miners are needed to set the nVe=
rsion in the header. So when you say "no additional bit is needed"=
;, could you please be clearer as to what you mean? Do you mean that signal=
ing of opposition in a block can be done without any "additional bit&q=
uot;? Or are you just saying that it is redundant to consider what miners m=
ight be opposing an upgrade?=C2=A0</div><div><br></div><div>@Jorge<br></div=
><div>> If different users want different incompatible things... there&#=
39;s no way to avoid the split</div><div><br></div><div>I agree. This happe=
ned with bcash, and that's fine. It was painful, but there were a signi=
ficant amount of users that disagreed, and they have the chain they want no=
w.</div><div><br></div><div><div>But we generally all want to avoid a chain=
split when possible. Because chain splits have a cost, and that cost can b=
e high, its likely that many users would rather choose the chain with the m=
ost support rather than choosing the chain with their preferred rules.</div=
></div><div><br></div><div>However, the question here is: how do we estimat=
e what fraction of users wants which rules? We don't have a divining ro=
d to determine with certainty what users want. We can only make polls of va=
rious levels of inaccuracy. The methods bitcoin has been using is community=
discussion and social consensus estimation as well as miner signaling duri=
ng the actual deployment period.=20
Neither of these are perfect, but they are both reasonable enough mechanism=
s. However, because both of these mechanisms are very rough estimates of us=
er sentiment, we need to consider the possibility that sometimes the estima=
te may be substantially inaccurate when we design deployment procedures. Th=
is inaccuracy is why we need multiple barriers in place for an upgrade, and=
why we need to have higher thresholds of success (require larger supermajo=
rities in both consensus and miner signaling).=C2=A0</div><div><br></div><d=
iv>Developers obviously care about bitcoin and have an incentive (personal =
and probably financial) to do it right. And miners have both an incentive t=
o keep the system healthy, as well as an incentive to mine on the chain tha=
t the economic majority of users is using. But measuring the consensus of t=
he bitcoin community can be extraordinarily difficult to do with consistent=
accuracy, and so I think miner signaling as it has been used as a second b=
arrier to entry for an upgrade is quite appropriate.=C2=A0</div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun=
27, 2021 at 2:22 AM Eric Voskuil <<a href=3D"mailto:eric@voskuil.org">e=
ric@voskuil.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">I have not objected to anyone splitting. As I said, a split =
is always possible, and of course has been done on a large scale. It is onl=
y the misleading statements about inherent soft fork =E2=80=9Ccompatibility=
=E2=80=9D and the implication that activation without hash power enforcemen=
t does not create a split that I object to. People who know better should b=
e honest about it.<br>
<br>
Far too many people have been led to believe there is some sort of activati=
on choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe =E2=80=9Cslo=
wed down=E2=80=9D). There is only a choice between creating a split and has=
h power enforcement. Soft forks are rule changes, and thereby incompatible =
- unless enforced by majority hash power.<br>
<br>
The statements below are grossly misleading and need to be called out as su=
ch so that people can actually make this decision you speak of. This idea t=
hat =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The quest=
ion is only how to avoid a split. If one does not care he can split at any =
time, no discussion required.<br>
<br>
e<br>
<br>
> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jtimon@jtimon.cc> w=
rote:<br>
> <br>
> =EF=BB=BFIf different users want different incompatible things (enough=
on each<br>
> side), there's no way to avoid the split. We shouldn't try to =
avoid<br>
> such a split.<br>
> Users decide the rules, not miners nor developers.<br>
> <br>
>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
>> <br>
>> Ultimately there is only one answer to this question. Get majority=
hash power support.<br>
>> <br>
>> Soft fork enforcement is the same act as any other censorship enfo=
rcement, the difference is only a question of what people want. Given that =
there is no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bitcoin re=
solves this question of conflicting wants, but it is not a democracy, it=E2=
=80=99s a market. One votes by trading.<br>
>> <br>
>> If one wants to enforce a soft fork (or otherwise censor) this is =
accomplished by mining (or paying others to do so). Anyone can mine, so eve=
ryone gets a say. Mining is trading capital now for more later. If enough p=
eople want to do that, they can enforce a soft fork. It=E2=80=99s time Bitc=
oiners stop thinking of miners as other people. Anyone can mine, and that=
=E2=80=99s your vote.<br>
>> <br>
>> Otherwise, as mentioned below, anyone can start a new coin. But it=
=E2=80=99s dishonest to imply that one can do this and all others will sure=
ly follow. This cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=
=99s one that has been shown to not always pay off.<br>
>> <br>
>> e<br>
>> <br>
>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <<a href=3D"mai=
lto:eric@voskuil.org" target=3D"_blank">eric@voskuil.org</a>> wrote:<br>
>>> <br>
>>> =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D.<br>
>>> <br>
>>> Without majority hash power support, activation simply means y=
ou are off on a chain split. Anyone can of course split off from a chain by=
changing a rule (soft or otherwise) at any time, so this is a bit of an em=
pty claim.<br>
>>> <br>
>>> Nobody can stop a person from splitting. The relevant question=
is how to *prevent* a split. And activation without majority hash power ce=
rtainly does not =E2=80=9Censure=E2=80=9D this.<br>
>>> <br>
>>> e<br>
>>> <br>
>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
>>>> <br>
>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block =
an upgrade entirely. They can<br>
>>>> still slow it down.<br>
>>>> <br>
>>>> It also already has the trinary state you seem to be descr=
ibing (although<br>
>>>> perhaps this could be better documented in the BIP): users=
who oppose the<br>
>>>> softfork can and should treat the successful signal (wheth=
er MASF or UASF) as<br>
>>>> invalid, thereby ensuring they do not follow a chain with =
the rules in force.<br>
>>>> <br>
>>>> No additional bit is needed, as softforks are coordinated =
between users, NOT<br>
>>>> miners (who have no particular say in them, aside from the=
ir role as also<br>
>>>> being users). The miner involvement is only out of necessi=
ty (to set the bit<br>
>>>> in the header, which users coordinate with) and potentiall=
y to accelerate<br>
>>>> activation by protecting upgrade-lagging users.<br>
>>>> <br>
>>>> Luke<br>
>>>> <br>
>>>> <br>
>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via=
bitcoin-dev wrote:<br>
>>>>> Given the recent controversy over upgrade mechanisms f=
or the<br>
>>>>> non-controversial taproot upgrade, I have been thinkin=
g about ways to solve<br>
>>>>> the problems that both sides brought up. In short, BIP=
8 LOT=3Dtrue proponents<br>
>>>>> make the point that lazy miners failing to upgrade in =
a timely manner slow<br>
>>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=
=3Dfalse<br>
>>>>> proponents make the point that LOT=3Dtrue can lead to =
undesirable forks that<br>
>>>>> might cause a lot of chaos. I believe both points are =
essentially correct<br>
>>>>> and have created a proposal<br>
>>>>> <<a href=3D"https://github.com/fresheneesz/bip-trin=
ary-version-signaling/blob/master/b" rel=3D"noreferrer" target=3D"_blank">h=
ttps://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b</=
a><br>
>>>>> ip-trinary-version-bits.md> for soft fork upgrades =
that solve both problems.<br>
>>>>> <br>
>>>>> The proposal uses trinary version signaling rather tha=
n binary signaling.<br>
>>>>> For any particular prospective soft fork upgrade, this=
allows for three<br>
>>>>> signaling states:<br>
>>>>> <br>
>>>>> * Actively support the change.<br>
>>>>> * Actively oppose the change.<br>
>>>>> * Not signaling (neither support or oppose). This is t=
he default state.<br>
>>>>> <br>
>>>>> Using this additional information, we can release non-=
contentious upgrades<br>
>>>>> much quicker (with a much lower percent of miners sign=
aling support). For<br>
>>>>> contentious upgrades, miners who oppose the change are=
incentivized to<br>
>>>>> update their software to a version that can actively s=
ignal opposition to<br>
>>>>> the change. The more opposition there is, the higher t=
he threshold<br>
>>>>> necessary to lock in the upgrade. With the parameters =
I currently<br>
>>>>> recommended in the proposal, this chart shows how much=
support signaling<br>
>>>>> would be necessary given a particular amount of active=
opposition<br>
>>>>> signaling:<br>
>>>>> <br>
>>>>> [image: thresholdChart.png]<br>
>>>>> If literally no one signals opposition, a 60% threshol=
d should be<br>
>>>>> relatively safe because it is a supermajority amount t=
hat is unlikely to<br>
>>>>> change significantly very quickly (ie if 60% of miners=
support the change<br>
>>>>> today, its unlikely that less than a majority of miner=
s would support the<br>
>>>>> change a year or two from now), and if no one is signa=
ling opposition,<br>
>>>>> chances are that the vast majority of the other 40% wo=
uld also eventually<br>
>>>>> signal support.<br>
>>>>> <br>
>>>>> This both gives an incentive for "lazy" mine=
rs to upgrade if they actually<br>
>>>>> oppose the change while at the same time allowing thes=
e lazy miners to<br>
>>>>> remain lazy without slowing down the soft fork activat=
ion much.<br>
>>>>> <br>
>>>>> I think now is the right time to discuss new soft fork=
upgrade mechanisms,<br>
>>>>> when there are no pressing soft fork upgrades ready to=
deploy. Waiting<br>
>>>>> until we need to deploy a soft fork to discuss this wi=
ll only delay things<br>
>>>>> and cause contention again like it did with taproot.<b=
r>
>>>>> <br>
>>>>> I'm very curious to know what people think of this=
mechanism. I would<br>
>>>>> appreciate any comments here, or written as github iss=
ues on the proposal<br>
>>>>> repo itself.<br>
>>>>> <br>
>>>>> Thanks,<br>
>>>>> BT<br>
>>>> <br>
>>>> _______________________________________________<br>
>>>> bitcoin-dev mailing list<br>
>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
>>>> <a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo=
undation.org/mailman/listinfo/bitcoin-dev</a><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/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000054f23705c5c34f2e--
|