summaryrefslogtreecommitdiff
path: root/63/9af22220cd150ba48625e99d6673c6490166b3
blob: 9d54086826751b9cb0796e5f2c8683771c321a25 (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
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
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
Return-Path: <michaelfolkson@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AA9BEC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 12:20:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 98AF787315
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 12:20:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Wx7pj2e-7j8a
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 12:20:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com
 [209.85.167.177])
 by hemlock.osuosl.org (Postfix) with ESMTPS id D9C2D872F3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 12:20:25 +0000 (UTC)
Received: by mail-oi1-f177.google.com with SMTP id l19so1735106oih.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Feb 2021 04:20:25 -0800 (PST)
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=jjwK7/YaRBPqQsr8eAeUWC/r9lmoOjnV8m/oDUzoDEA=;
 b=NZZuAIPepS41GQkoXFiZ2LuiLNrY86Na3x2XtI9SfwlidP2iTWRCQ6mIrIr4kOhrCY
 tIIVtLH9jdllXI8C4JSID3ZrYxjfxamdr6jigu6OBybSsu3nQkoziHyKyZhay2njNKT7
 L2EyZJCq8Eh7clkNbjw6HUa3t+8/7mJc8t+TChWskj4QVyCZYmlZOATjW9Ch4nwdwUOd
 SZ36/7h3nUVUHTilGDPM2aw1w/DI0s6ncxuEotXWZfe3ddMQMk+NXSjlhNJjm6rQabEr
 bxu1sC8womdklOxFQkQEbqPsnCryUQh19eYmM2zPRyWpxDuJs4eG4QkMAwt3v1ql4mTN
 sbLg==
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=jjwK7/YaRBPqQsr8eAeUWC/r9lmoOjnV8m/oDUzoDEA=;
 b=AT8klVjbM/dfD54Nx4DrGAZDrYUXKmUaTxr0DpGXtV8x6teRGnWDpwkTg7oRB4+s2d
 YsoH6TJDrFyxXoYklTrSCuTCJKcaCJaon4MobrVpguAZLHivz4a9Ph+v8GeF2sAw1PB8
 0nXrmKx1ANKrIs3bAlMpzWD27Lq/DNb1vxy8yhAmQrIlOtBftTy2U8TvQJJT3UR8wyFl
 isGZoS5ge2bqWmCqf0q27lhNP9t+m8Bdg79B9lIhimdoQkJuOjB7yVkwiCoMi2fLb4ak
 2hea+5xu9G2o7gfqoqmfO/oD2n8XI1DRJn57a1VFpgAJYESYMElKGTCtfNIP/oKCgVaz
 xCvA==
X-Gm-Message-State: AOAM531P6hHV9lMQk58LVuPXXoALMyFxBlBAzOmabJUJ+8l/6cr+6Lx0
 9C3qkUin0ti0R86eNvPNDX+wKeEkQxgKXF7dOKQ=
X-Google-Smtp-Source: ABdhPJxf0aCgWlJxmuA9EcTQjhxFfNXciws5S07g7HgWtlcKmwUDURsGJFjzNInUmQ48xumIi1G9mU07wV2VZsfktI4=
X-Received: by 2002:aca:af91:: with SMTP id y139mr2543998oie.88.1613650825003; 
 Thu, 18 Feb 2021 04:20:25 -0800 (PST)
MIME-Version: 1.0
References: <CAFvNmHTGkQJnsp7J8q0W3rf2j_djO0J0GNFzrhTpdAvN1GihEA@mail.gmail.com>
 <8231ddff-aaa4-4ee0-b25f-40ba9a540aab@gmail.com>
 <CAFvNmHSiZhJQ455=RkUVU00ZqagimjGPg_fhC-8oJV=WwM_o=Q@mail.gmail.com>
 <CAAWeQ5fH+pbEx32uEc4gs_arQC7o+GS+HpVeAZGsKr8i6ewL5w@mail.gmail.com>
 <vMdhML4Coj8h6x3LS3kWrMXcINOLKmWOyVzElVr5TZ-nf4FkzDjmQsSaoyYcxL_f74rEI3NUX7JAmXprBSxqOzGi7ZNRhwluA_5f1oqa5oM=@protonmail.com>
In-Reply-To: <vMdhML4Coj8h6x3LS3kWrMXcINOLKmWOyVzElVr5TZ-nf4FkzDjmQsSaoyYcxL_f74rEI3NUX7JAmXprBSxqOzGi7ZNRhwluA_5f1oqa5oM=@protonmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Thu, 18 Feb 2021 12:20:14 +0000
Message-ID: <CAFvNmHSHu0gqVgWxOCJnSTf5mxpWsMF9FrMQ+_X+uyR3P4QCsg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000037447705bb9b5ce9"
X-Mailman-Approved-At: Thu, 18 Feb 2021 13:10:47 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
 lockinontimeout (LOT)
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: Thu, 18 Feb 2021 12:20:28 -0000

--00000000000037447705bb9b5ce9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Right, that is one option. Personally I would prefer a Bitcoin Core release
sets LOT=3Dfalse (based on what I have heard from Bitcoin Core contributors=
)
and a community effort releases a version with LOT=3Dtrue. I don't think
users should be forced to choose something they may have no context on
before they are allowed to use Bitcoin Core.

My current understanding is that roasbeef is planning to set LOT=3Dfalse on
btcd (an alternative protocol implementation to Bitcoin Core) and Luke
Dashjr hasn't yet decided on Bitcoin Knots.



On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning all,
>
> > "An activation mechanism is a consensus change like any other change,
> can be contentious like any other change, and we must resolve it like any
> other change. Otherwise we risk arriving at the darkest timeline."
> >
> > Who's we here?
> >
> > Release both and let the network decide.
>
> A thing that could be done, without mandating either LOT=3Dtrue or
> LOT=3Dfalse, would be to have a release that requires a `taprootlot=3D1` =
or
> `taprootlot=3D0` and refuses to start if the parameter is not set.
>
> This assures everyone that neither choice is being forced on users, and
> instead what is being forced on users, is for users to make that choice
> themselves.
>
> Regards,
> ZmnSCPxj
>
> >
> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > Thanks for your response Ariel. It would be useful if you responded t=
o
> specific points I have made in the mailing list post or at least quote
> these ephemeral "people" you speak of. I don't know if you're responding =
to
> conversation on the IRC channel or on social media etc.
> > >
> > > > The argument comes from a naive assumption that users MUST upgrade
> to the choice that is submitted into code. But in fact this isn't true an=
d
> some voices in this discussion need to be more humble about what users mu=
st
> or must not run.
> > >
> > > I personally have never made this assumption. Of course users aren't
> forced to run any particular software version, quite the opposite. Defaul=
ts
> set in software versions matter though as many users won't change them.
> > >
> > > > Does no one realize that it is a very possible outcome that if
> LOT=3Dtrue is released there may be only a handful of people that begin
> running it while everyone else delays their upgrade (with the very good
> reason of not getting involved in politics) and a year later those handfu=
l
> of people just become stuck at the moment of MUST_SIGNAL, unable to mine
> new blocks?
> > >
> > > It is a possible outcome but the likely outcome is that miners
> activate Taproot before LOT is even relevant. I think it is prudent to
> prepare for the unlikely but possible outcome that miners fail to activat=
e
> and hence have this discussion now rather than be unprepared for that
> eventuality. If LOT is set to false in a software release there is the
> possibility (T2 in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
380.html)
> of individuals or a proportion of the community changing LOT to true. In
> that sense setting LOT=3Dfalse in a software release appears to be no mor=
e
> safe than LOT=3Dtrue.
> > >
> > > > The result: a wasted year of waiting and a minority of people who
> didn't want to be lenient with miners by default.
> > >
> > > There is the (unlikely but possible) possibility of a wasted year if
> LOT is set to false and miners fail to activate. I'm not convinced by thi=
s
> perception that LOT=3Dtrue is antagonistic to miners. I actually think it
> offers them clarity on what will happen over a year time period and remov=
es
> the need for coordinated or uncoordinated community UASF efforts on top o=
f
> LOT=3Dfalse.
> > >
> > > > An activation mechanism is a consensus change like any other change=
,
> can be contentious like any other change, and we must resolve it like any
> other change. Otherwise we risk arriving at the darkest timeline.
> > >
> > > I don't know what you are recommending here to avoid "this darkest
> timeline". Open discussions have occurred and are continuing and in my
> mailing list post that you responded to **I recommended we propose
> LOT=3Dfalse be set in protocol implementations such as Bitcoin Core**. I =
do
> think this apocalyptic language isn't particularly helpful. In an open
> consensus system discussion is healthy, we should prepare for bad or wors=
t
> case scenarios in advance and doing so is not antagonistic or destructive=
.
> Mining pools have pledged support for Taproot but we don't build secure
> systems based on pledges of support, we build them to minimize trust in a=
ny
> human actors. We can be grateful that people like Alejandro have worked
> hard on taprootactivation.com (and this effort has informed the
> discussion) without taking pledges of support as cast iron guarantees.
> > >
> > > TL;DR It sounds like you agree with my recommendation to set LOT=3Dfa=
lse
> in protocol implementations in my email :)
> > >
> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
> arielluaces@gmail.com> wrote:
> > >
> > > > Something what strikes me about the conversation is the emotion
> surrounding the letters UASF.
> > > > It appears as if people discuss UASF as if it's a massive tidal wav=
e
> of support that is inevitable, like we saw during segwit activation. But
> the actual definition is "any activation that is not a MASF".
> > > > A UASF can consist of a single node, ten nodes, a thousand, half of
> all nodes, all business' nodes, or even all the non mining nodes. On
> another dimension it can have zero mining support, 51% support, 49%
> support, or any support right up against a miner activation threshold.
> > > > Hell a UASF doesn't even need code or even a single node running as
> long as it exists as a possibility in people's minds.
> > > > The only thing a UASF doesn't have is miner support above an agreed
> activation threshold (some number above %51).
> > > > I say this because it strikes me when people say that they are for
> LOT=3Dtrue with the logic that since a UASF is guaranteed to happen then =
it's
> better to just make it default from the beginning. Words like coordinatio=
n
> and safety are sometimes sprinkled into the argument.
> > > > The argument comes from a naive assumption that users MUST upgrade
> to the choice that is submitted into code. But in fact this isn't true an=
d
> some voices in this discussion need to be more humble about what users mu=
st
> or must not run.
> > > > Does no one realize that it is a very possible outcome that if
> LOT=3Dtrue is released there may be only a handful of people that begin
> running it while everyone else delays their upgrade (with the very good
> reason of not getting involved in politics) and a year later those handfu=
l
> of people just become stuck at the moment of MUST_SIGNAL, unable to mine
> new blocks? Or attracting a minority of miners, activating, and forking o=
ff
> into a minority fork. Then a lot=3Dfalse could be started that ends up
> activating the feature now that the stubborn option has ran its course.
> > > > The result: a wasted year of waiting and a minority of people who
> didn't want to be lenient with miners by default. The chains could be
> called BitcoinLenient and BitcoinStubborn.
> > > > How is that strictly safer or more coordinated?
> > > > I may be in the minority, or maybe a silent majority, or maybe a
> majority that just hasn't considered this as a choice but honestly if the=
re
> is contention about whether we're going to be stubborn or lenient with
> miners for Taproot and in the future then I prefer to just not activate
> anything at all. I'm fine for calling bitcoin ossified, accepting that
> segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
> feature is worth a network split down the middle.
> > > > Maybe in 10 or 20 years, when other blockchains implement features
> like Taproot and many more, we will become envious enough to put aside ou=
r
> differences on how to behave towards miners and finally activate Taproot.
> > > > An activation mechanism is a consensus change like any other change=
,
> can be contentious like any other change, and we must resolve it like any
> other change. Otherwise we risk arriving at the darkest timeline.
> > > > Cheers
> > > > Ariel Lorenzo-Luaces
> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > >
> > > > > Yesterday (February 16th) we held a second meeting on Taproot
> > > > > activation on IRC which again was open to all. Despite what
> appeared
> > > > > to be majority support for LOT=3Dfalse over LOT=3Dtrue in the fir=
st
> > > > > meeting I (and others) thought the arguments had not been explore=
d
> in
> > > > > depth and that we should have a follow up meeting almost entirely
> > > > > focused on whether LOT (lockinontimeout) should be set to true or
> > > > > false.
> > > > >
> > > > > The meeting was announced here:
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
380.html
> > > > >
> > > > > In that mailing list post I outlined the arguments for LOT=3Dtrue
> (T1 to
> > > > > T6) and arguments for LOT=3Dfalse (F1 to F6) in their strongest f=
orm
> I
> > > > > could. David Harding responded with an additional argument for
> > > > > LOT=3Dfalse (F7) here:
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
415.html
> > > > >
> > > > > These meetings are very challenging given they are open to all, y=
ou
> > > > > don=E2=80=99t know who will attend and you don=E2=80=99t know mos=
t people=E2=80=99s views
> in
> > > > > advance. I tried to give time for both the LOT=3Dtrue arguments a=
nd
> the
> > > > > LOT=3Dfalse arguments to be discussed as I knew there was support=
 for
> > > > > both. We only tried evaluating which had more support and which h=
ad
> > > > > more strong opposition towards the end of the meeting.
> > > > >
> > > > > The conversation log is here:
> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
> > > > >
> > > > > (If you are so inclined you can watch a video of the meeting here=
.
> > > > > Thanks to the YouTube account =E2=80=9CBitcoin=E2=80=9D for setti=
ng up the
> livestream:
> > > > > https://www.youtube.com/watch?v=3Dvpl5q1ovMLM)
> > > > >
> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon
> here:
> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
> > > > >
> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive,
> but we
> > > > > did manage to come to consensus on everything but LockinOnTimeout=
.
> > > > >
> > > > > Activation height range: 693504-745920
> > > > >
> > > > > MASF threshold: 1815/2016 blocks (90%)
> > > > >
> > > > > Keep in mind only ~100 people showed for the meetings, hardly
> > > > > representative of the entire community.
> > > > >
> > > > > So, these details remain JUST a proposal for now.
> > > > >
> > > > > It seems inevitable that there won't be consensus on LOT.
> > > > >
> > > > > Everyone will have to choose for himself. :/
> > > > >
> > > > > Personally I agree with most of this. I agree that there wasn=E2=
=80=99t
> > > > > overwhelming consensus for either LOT=3Dtrue or LOT=3Dfalse. Howe=
ver,
> from
> > > > > my perspective there was clearly more strong opposition (what wou=
ld
> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
> > > > > Bitcoin Core contributors, Lightning developers and other communi=
ty
> > > > > members against LOT=3Dtrue than there was for LOT=3Dfalse. Andrew=
 Chow
> > > > > tried to summarize views from the meeting in this analysis:
> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> > > > >
> > > > > I am also aware of other current and previous Bitcoin Core
> > > > > contributors and Lightning developers who didn=E2=80=99t attend t=
he
> meeting in
> > > > > person who are opposed to LOT=3Dtrue. I don=E2=80=99t want to put=
 them in the
> > > > > spotlight for no reason but if you go through the conversation
> logs of
> > > > > not only the meeting but the weeks of discussion prior to this
> meeting
> > > > > you will see their views evaluated on the ##taproot-activation
> > > > > channel. In addition, on taprootactivation.com some mining pools
> > > > > expressed a preference for lot=3Dfalse though I don=E2=80=99t kno=
w how strong
> > > > > that preference was.
> > > > >
> > > > > I am only one voice but it is my current assessment that if we ar=
e
> to
> > > > > attempt to finalize Taproot activation parameters and propose the=
m
> to
> > > > > the community at this time our only option is to propose LOT=3Dfa=
lse.
> > > > > Any further delay appears to me counterproductive in our collecti=
ve
> > > > > aim to get the Taproot soft fork activated as early as possible.
> > > > >
> > > > > Obviously others are free to disagree with that assessment and
> > > > > continue discussions but personally I will be attempting to avoid
> > > > > those discussions unless prominent new information comes to light
> or
> > > > > various specific individuals change their minds.
> > > > >
> > > > > Next week we are planning a code review of the Bitcoin Core PR
> #19573
> > > > > which was initially delayed because of this LOT discussion. As I=
=E2=80=99ve
> > > > > said previously that will be loosely following the format of the
> > > > > Bitcoin Core PR review club and will be lower level and more
> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC
> on
> > > > > the IRC channel ##taproot-activation.
> > > > >
> > > > > Thanks to the meeting participants (and those who joined the
> > > > > discussion on the channel prior and post the meeting) for engagin=
g
> > > > > productively and in good faith.
> > >
> > > --
> > > Michael Folkson
> > > Email: michaelfolkson@gmail.com
> > > Keybase: michaelfolkson
> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--00000000000037447705bb9b5ce9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Right, that is one option. Personally I would prefer a Bit=
coin Core release sets LOT=3Dfalse (based on what I have heard from Bitcoin=
 Core contributors) and a community effort releases a version with LOT=3Dtr=
ue. I don&#39;t think users should be forced to choose something they may h=
ave no context on before they are allowed to use Bitcoin Core.=C2=A0<div><b=
r></div><div>My current understanding is that roasbeef is planning to set L=
OT=3Dfalse on btcd (an alternative protocol implementation to Bitcoin Core)=
 and Luke Dashjr hasn&#39;t yet decided on Bitcoin Knots.</div><div><div><b=
r></div><div><br></div></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj &lt=
;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good mor=
ning all,<br>
<br>
&gt; &quot;An activation mechanism is a consensus change like any other cha=
nge, can be contentious like any other change, and we must resolve it like =
any other change. Otherwise we risk arriving at the darkest timeline.&quot;=
<br>
&gt;<br>
&gt; Who&#39;s we here?<br>
&gt;<br>
&gt; Release both and let the network decide.<br>
<br>
A thing that could be done, without mandating either LOT=3Dtrue or LOT=3Dfa=
lse, would be to have a release that requires a `taprootlot=3D1` or `taproo=
tlot=3D0` and refuses to start if the parameter is not set.<br>
<br>
This assures everyone that neither choice is being forced on users, and ins=
tead what is being forced on users, is for users to make that choice themse=
lves.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
&gt;<br>
&gt; On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev &lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Thanks for your response Ariel. It would be useful if you respond=
ed to specific points I have made in the mailing list post or at least quot=
e these ephemeral &quot;people&quot; you speak of. I don&#39;t know if you&=
#39;re responding to conversation on the IRC channel or on social media etc=
.<br>
&gt; &gt;<br>
&gt; &gt; &gt; The argument comes from a naive assumption that users MUST u=
pgrade to the choice that is submitted into code. But in fact this isn&#39;=
t true and some voices in this discussion need to be more humble about what=
 users must or must not run.<br>
&gt; &gt;<br>
&gt; &gt; I personally have never made this assumption. Of course users are=
n&#39;t forced to run any particular software version, quite the opposite. =
Defaults set in software versions matter though as many users won&#39;t cha=
nge them.<br>
&gt; &gt;<br>
&gt; &gt; &gt; Does no one realize that it is a very possible outcome that =
if LOT=3Dtrue is released there may be only a handful of people that begin =
running it while everyone else delays their upgrade (with the very good rea=
son of not getting involved in politics) and a year later those handful of =
people just become stuck at the moment of MUST_SIGNAL, unable to mine new b=
locks?<br>
&gt; &gt;<br>
&gt; &gt; It is a possible outcome but the likely outcome is that miners ac=
tivate Taproot before LOT is even relevant. I think it is prudent to prepar=
e for the unlikely but possible outcome that miners fail to activate and he=
nce have this discussion now rather than be unprepared for that eventuality=
. If LOT is set to false in a software release there is the possibility (T2=
 in=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2021-February/018380.html" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html</a>=
) of individuals or a proportion of the community changing LOT to true. In =
that sense setting LOT=3Dfalse in a software release appears to be no more =
safe than LOT=3Dtrue.<br>
&gt; &gt;<br>
&gt; &gt; &gt; The result: a wasted year of waiting and a minority of peopl=
e who didn&#39;t want to be lenient with miners by default.<br>
&gt; &gt;<br>
&gt; &gt; There is the (unlikely but possible) possibility of a wasted year=
 if LOT is set to false and miners fail to activate. I&#39;m not convinced =
by this perception that LOT=3Dtrue is antagonistic to miners. I actually th=
ink it offers them clarity on what will happen over a year time period and =
removes the need for coordinated or uncoordinated community UASF efforts on=
 top of LOT=3Dfalse.<br>
&gt; &gt;<br>
&gt; &gt; &gt; An activation mechanism is a consensus change like any other=
 change, can be contentious like any other change, and we must resolve it l=
ike any other change. Otherwise we risk arriving at the darkest timeline.<b=
r>
&gt; &gt;<br>
&gt; &gt; I don&#39;t know what you are recommending here to avoid &quot;th=
is darkest timeline&quot;. Open discussions have occurred and are continuin=
g and in my mailing list post that you responded to **I recommended we prop=
ose LOT=3Dfalse be set in protocol implementations such as Bitcoin Core**. =
I do think this apocalyptic language isn&#39;t particularly helpful. In an =
open consensus system discussion is healthy, we should prepare for bad or w=
orst case scenarios in advance and doing so is not antagonistic or destruct=
ive. Mining pools=C2=A0have pledged support for Taproot but we don&#39;t bu=
ild secure systems based on pledges of support, we build them to minimize t=
rust in any human actors. We can be grateful that people like Alejandro hav=
e worked hard on <a href=3D"http://taprootactivation.com" rel=3D"noreferrer=
" target=3D"_blank">taprootactivation.com</a> (and this effort has informed=
 the discussion) without taking pledges of support as cast iron guarantees.=
<br>
&gt; &gt;<br>
&gt; &gt; TL;DR It sounds like you agree with my recommendation to set LOT=
=3Dfalse in protocol implementations in my email :)<br>
&gt; &gt;<br>
&gt; &gt; On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces &lt;<a href=
=3D"mailto:arielluaces@gmail.com" target=3D"_blank">arielluaces@gmail.com</=
a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Something what strikes me about the conversation is the emot=
ion surrounding the letters UASF.<br>
&gt; &gt; &gt; It appears as if people discuss UASF as if it&#39;s a massiv=
e tidal wave of support that is inevitable, like we saw during segwit activ=
ation. But the actual definition is &quot;any activation that is not a MASF=
&quot;.<br>
&gt; &gt; &gt; A UASF can consist of a single node, ten nodes, a thousand, =
half of all nodes, all business&#39; nodes, or even all the non mining node=
s. On another dimension it can have zero mining support, 51% support, 49% s=
upport, or any support right up against a miner activation threshold.<br>
&gt; &gt; &gt; Hell a UASF doesn&#39;t even need code or even a single node=
 running as long as it exists as a possibility in people&#39;s minds.<br>
&gt; &gt; &gt; The only thing a UASF doesn&#39;t have is miner support abov=
e an agreed activation threshold (some number above %51).<br>
&gt; &gt; &gt; I say this because it strikes me when people say that they a=
re for LOT=3Dtrue with the logic that since a UASF is guaranteed to happen =
then it&#39;s better to just make it default from the beginning. Words like=
 coordination and safety are sometimes sprinkled into the argument.<br>
&gt; &gt; &gt; The argument comes from a naive assumption that users MUST u=
pgrade to the choice that is submitted into code. But in fact this isn&#39;=
t true and some voices in this discussion need to be more humble about what=
 users must or must not run.<br>
&gt; &gt; &gt; Does no one realize that it is a very possible outcome that =
if LOT=3Dtrue is released there may be only a handful of people that begin =
running it while everyone else delays their upgrade (with the very good rea=
son of not getting involved in politics) and a year later those handful of =
people just become stuck at the moment of MUST_SIGNAL, unable to mine new b=
locks? Or attracting a minority of miners, activating, and forking off into=
 a minority fork. Then a lot=3Dfalse could be started that ends up activati=
ng the feature now that the stubborn option has ran its course.<br>
&gt; &gt; &gt; The result: a wasted year of waiting and a minority of peopl=
e who didn&#39;t want to be lenient with miners by default. The chains coul=
d be called BitcoinLenient and BitcoinStubborn.<br>
&gt; &gt; &gt; How is that strictly safer or more coordinated?<br>
&gt; &gt; &gt; I may be in the minority, or maybe a silent majority, or may=
be a majority that just hasn&#39;t considered this as a choice but honestly=
 if there is contention about whether we&#39;re going to be stubborn or len=
ient with miners for Taproot and in the future then I prefer to just not ac=
tivate anything at all. I&#39;m fine for calling bitcoin ossified, acceptin=
g that segwit is Bitcoin&#39;s last network upgrade. Taproot is amazing but=
 no new feature is worth a network split down the middle.<br>
&gt; &gt; &gt; Maybe in 10 or 20 years, when other blockchains implement fe=
atures like Taproot and many more, we will become envious enough to put asi=
de our differences on how to behave towards miners and finally activate Tap=
root.<br>
&gt; &gt; &gt; An activation mechanism is a consensus change like any other=
 change, can be contentious like any other change, and we must resolve it l=
ike any other change. Otherwise we risk arriving at the darkest timeline.<b=
r>
&gt; &gt; &gt; Cheers<br>
&gt; &gt; &gt; Ariel Lorenzo-Luaces<br>
&gt; &gt; &gt; On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Yesterday (February 16th) we held a second meeting on T=
aproot<br>
&gt; &gt; &gt; &gt; activation on IRC which again was open to all. Despite =
what appeared<br>
&gt; &gt; &gt; &gt; to be majority support for LOT=3Dfalse over LOT=3Dtrue =
in the first<br>
&gt; &gt; &gt; &gt; meeting I (and others) thought the arguments had not be=
en explored in<br>
&gt; &gt; &gt; &gt; depth and that we should have a follow up meeting almos=
t entirely<br>
&gt; &gt; &gt; &gt; focused on whether LOT (lockinontimeout) should be set =
to true or<br>
&gt; &gt; &gt; &gt; false.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The meeting was announced here:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2021-February/018380.html" rel=3D"noreferrer" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/0183=
80.html</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; In that mailing list post I outlined the arguments for =
LOT=3Dtrue (T1 to<br>
&gt; &gt; &gt; &gt; T6) and arguments for LOT=3Dfalse (F1 to F6) in their s=
trongest form I<br>
&gt; &gt; &gt; &gt; could. David Harding responded with an additional argum=
ent for<br>
&gt; &gt; &gt; &gt; LOT=3Dfalse (F7) here:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2021-February/018415.html" rel=3D"noreferrer" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/0184=
15.html</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; These meetings are very challenging given they are open=
 to all, you<br>
&gt; &gt; &gt; &gt; don=E2=80=99t know who will attend and you don=E2=80=99=
t know most people=E2=80=99s views in<br>
&gt; &gt; &gt; &gt; advance. I tried to give time for both the LOT=3Dtrue a=
rguments and the<br>
&gt; &gt; &gt; &gt; LOT=3Dfalse arguments to be discussed as I knew there w=
as support for<br>
&gt; &gt; &gt; &gt; both. We only tried evaluating which had more support a=
nd which had<br>
&gt; &gt; &gt; &gt; more strong opposition towards the end of the meeting.<=
br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The conversation log is here:<br>
&gt; &gt; &gt; &gt; <a href=3D"http://gnusha.org/taproot-activation/2021-02=
-16.log" rel=3D"noreferrer" target=3D"_blank">http://gnusha.org/taproot-act=
ivation/2021-02-16.log</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; (If you are so inclined you can watch a video of the me=
eting here.<br>
&gt; &gt; &gt; &gt; Thanks to the YouTube account =E2=80=9CBitcoin=E2=80=9D=
 for setting up the livestream:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://www.youtube.com/watch?v=3Dvpl5q1ovML=
M" rel=3D"noreferrer" target=3D"_blank">https://www.youtube.com/watch?v=3Dv=
pl5q1ovMLM</a>)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; A summary of the meeting was provided by Luke Dashjr on=
 Mastodon here:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://bitcoinhackers.org/@lukedashjr/10574=
2918779234566" rel=3D"noreferrer" target=3D"_blank">https://bitcoinhackers.=
org/@lukedashjr/105742918779234566</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Today&#39;s #Bitcoin #Taproot meeting was IMO largely u=
nproductive, but we<br>
&gt; &gt; &gt; &gt; did manage to come to consensus on everything but Locki=
nOnTimeout.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Activation height range: 693504-745920<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; MASF threshold: 1815/2016 blocks (90%)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Keep in mind only ~100 people showed for the meetings, =
hardly<br>
&gt; &gt; &gt; &gt; representative of the entire community.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; So, these details remain JUST a proposal for now.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; It seems inevitable that there won&#39;t be consensus o=
n LOT.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Everyone will have to choose for himself. :/<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Personally I agree with most of this. I agree that ther=
e wasn=E2=80=99t<br>
&gt; &gt; &gt; &gt; overwhelming consensus for either LOT=3Dtrue or LOT=3Df=
alse. However, from<br>
&gt; &gt; &gt; &gt; my perspective there was clearly more strong opposition=
 (what would<br>
&gt; &gt; &gt; &gt; usually be deemed a NACK in Bitcoin Core review termino=
logy) from<br>
&gt; &gt; &gt; &gt; Bitcoin Core contributors, Lightning developers and oth=
er community<br>
&gt; &gt; &gt; &gt; members against LOT=3Dtrue than there was for LOT=3Dfal=
se. Andrew Chow<br>
&gt; &gt; &gt; &gt; tried to summarize views from the meeting in this analy=
sis:<br>
&gt; &gt; &gt; &gt; <a href=3D"https://gist.github.com/achow101/3e179501290=
abb7049de198d46894c7c" rel=3D"noreferrer" target=3D"_blank">https://gist.gi=
thub.com/achow101/3e179501290abb7049de198d46894c7c</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I am also aware of other current and previous Bitcoin C=
ore<br>
&gt; &gt; &gt; &gt; contributors and Lightning developers who didn=E2=80=99=
t attend the meeting in<br>
&gt; &gt; &gt; &gt; person who are opposed to LOT=3Dtrue. I don=E2=80=99t w=
ant to put them in the<br>
&gt; &gt; &gt; &gt; spotlight for no reason but if you go through the conve=
rsation logs of<br>
&gt; &gt; &gt; &gt; not only the meeting but the weeks of discussion prior =
to this meeting<br>
&gt; &gt; &gt; &gt; you will see their views evaluated on the ##taproot-act=
ivation<br>
&gt; &gt; &gt; &gt; channel. In addition, on <a href=3D"http://taprootactiv=
ation.com" rel=3D"noreferrer" target=3D"_blank">taprootactivation.com</a> s=
ome mining pools<br>
&gt; &gt; &gt; &gt; expressed a preference for lot=3Dfalse though I don=E2=
=80=99t know how strong<br>
&gt; &gt; &gt; &gt; that preference was.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I am only one voice but it is my current assessment tha=
t if we are to<br>
&gt; &gt; &gt; &gt; attempt to finalize Taproot activation parameters and p=
ropose them to<br>
&gt; &gt; &gt; &gt; the community at this time our only option is to propos=
e LOT=3Dfalse.<br>
&gt; &gt; &gt; &gt; Any further delay appears to me counterproductive in ou=
r collective<br>
&gt; &gt; &gt; &gt; aim to get the Taproot soft fork activated as early as =
possible.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Obviously others are free to disagree with that assessm=
ent and<br>
&gt; &gt; &gt; &gt; continue discussions but personally I will be attemptin=
g to avoid<br>
&gt; &gt; &gt; &gt; those discussions unless prominent new information come=
s to light or<br>
&gt; &gt; &gt; &gt; various specific individuals change their minds.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Next week we are planning a code review of the Bitcoin =
Core PR #19573<br>
&gt; &gt; &gt; &gt; which was initially delayed because of this LOT discuss=
ion. As I=E2=80=99ve<br>
&gt; &gt; &gt; &gt; said previously that will be loosely following the form=
at of the<br>
&gt; &gt; &gt; &gt; Bitcoin Core PR review club and will be lower level and=
 more<br>
&gt; &gt; &gt; &gt; technical. That is planned for Tuesday February 23rd at=
 19:00 UTC on<br>
&gt; &gt; &gt; &gt; the IRC channel ##taproot-activation.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Thanks to the meeting participants (and those who joine=
d the<br>
&gt; &gt; &gt; &gt; discussion on the channel prior and post the meeting) f=
or engaging<br>
&gt; &gt; &gt; &gt; productively and in good faith.<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Michael Folkson<br>
&gt; &gt; Email:=C2=A0<a href=3D"mailto:michaelfolkson@gmail.com" target=3D=
"_blank">michaelfolkson@gmail.com</a><br>
&gt; &gt; Keybase: michaelfolkson<br>
&gt; &gt; PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div=
 dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D=
"ltr"><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">Michael=
 Folkson</font><div><font face=3D"arial, helvetica, sans-serif" color=3D"#0=
00000">Email:=C2=A0<a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_b=
lank">michaelfolkson@gmail.com</a></font></div><div><font face=3D"arial, he=
lvetica, sans-serif" color=3D"#000000">Keybase: michaelfolkson</font></div>=
<div><font face=3D"arial, helvetica, sans-serif" color=3D"#000000">PGP: 43E=
D C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</font></div></div></div></di=
v></div></div></div></div></div></div></div>

--00000000000037447705bb9b5ce9--