summaryrefslogtreecommitdiff
path: root/c0/0f8c3254c004d02660ce8411a747e3559e53df
blob: 7e9b4c26784e5c95ad5c82a02fdde257ab3770fb (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
Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2D593C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 14:44:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 0FBE742FFD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 14:44:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.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 VaKI4I9FpX6C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 14:44:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com
 [IPv6:2607:f8b0:4864:20::f2c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id D170442FB0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 14:44:56 +0000 (UTC)
Received: by mail-qv1-xf2c.google.com with SMTP id cw15so2458836qvb.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 06 Mar 2021 06:44:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=1qs4J4JF3HscUWLZ6NOZlGYXG4WiDTyYc6AIUZQoC1Y=;
 b=XH9XvFOZGeLU7QxecQ2z54tPCCXeZ7Sso+1z4pFfVy+/15OVXTU6SWcAcjJl5N+5Wh
 vpUFOvvZ6vxlg7q0KsD9zuBAkZlH7Mn/c/0zwtemuuCjUl9jHNcePdpiGCSpRIAtSnXv
 SsLXQ1EldzLVO2rt4GmbpCurLiuXI2pgJdkU0ChA8LKIQqEMlfud5urEtyD/XpmtMI7z
 YRcA+SWrhlnk0o+b42E7aeiRq0iC8x0N6pNxzYdDFHsKtjLneLCA79yFUhbOYQZyre8M
 byrArxV+WgC+785eDT3vMfI0Yd5jz+E+eW7Y7loqjrB82klLnsxoqBU0WBPNyydWLSIs
 710Q==
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;
 bh=1qs4J4JF3HscUWLZ6NOZlGYXG4WiDTyYc6AIUZQoC1Y=;
 b=nGSnAmEveXOEkBw/5sEk+s3u4MEepDd29JFBxYX4JvwgZMmT/0STSbCJqHQF8BzwJl
 y9cPpbqhkfC6cZ5v+CgOSP00APEIhDDa1C77nUXiz3M7qNDlVhps7zvgcDusHH/jeFdF
 hsvDGzIeUToHpLKzGzplFtww6gs5V5h/ztp4kQbQKlaWn5U8yZ3ooy+hGzZQwhQdYR6+
 m71d/oDJWTKxRPQLGCocpsuqQH+XEH0Rs1GKCgYpbLGtHU53QnmLcBWanP28MAjx8YQd
 J9PDR6LLbOureGQemyDltUFuMhqGG+oAguGjbKWujqUFNFY9QosJ2I6o7aTT0/lLyjWN
 YABQ==
X-Gm-Message-State: AOAM531fNr8MLaLCDh9JxFtPBVZkBkRwm07W3wcFBVTNsGAqktBHoBlk
 /LsLeDwgAyL41mm8/2ABHkIK7H53Umztpu3ycKzaYARujqESEYMV
X-Google-Smtp-Source: ABdhPJxL75fZwyp2vBia3AOf1CB31/Hz83mhQE8mj1hfbEMElyypL/DfUoCKu+23xnX+tRk2jQcXL/QfS5G35z54KyY=
X-Received: by 2002:a0c:ea81:: with SMTP id d1mr13412091qvp.57.1615041895527; 
 Sat, 06 Mar 2021 06:44:55 -0800 (PST)
MIME-Version: 1.0
References: <20210306034343.fhwrxmq6gbb2os5m@ganymede>
 <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com>
In-Reply-To: <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sat, 6 Mar 2021 09:44:44 -0500
Message-ID: <CAMZUoKmxkHE_d2jTy-a2F9Xr7HxNNb3oyAZ4Wr=4kf8qTP5bdw@mail.gmail.com>
To: Andrew Chow <achow101-lists@achow101.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007b0f6d05bcdf3e6b"
Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2021 14:44:59 -0000

--0000000000007b0f6d05bcdf3e6b
Content-Type: text/plain; charset="UTF-8"

Hi Andrew,

This is a slight misunderstanding of the proposal.  Rather than an extended
lockin period (a term I've erroneously used in the past) it is really a
minimum activation height.

Thus using your figures it would instead be:

* start height = 681408 /* about May 1st */
* timeout height = 695520 /* about Aug 7th */
* min activation height = 709632 /* about Nov 13th */
* lockinontimeout = False
* signaling bit = 2
* threshold = 1815/2016 blocks (90%)

This guarantees 7 retargeting periods between start height and timeout
height.

Being able to make a guarantee about how many retargeting periods we get is
perhaps something worth pursuing given that the signaling period is so
short for this trial.

On Sat, Mar 6, 2021 at 1:04 AM Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I like this idea.
>
> In terms of actual parameters, I propose that we base this Speedy Trial
> off of BIP 8 with the following parameters:
> * start height = 681408
> * timeout height = 695520
> * lockinontimeout = False
> * signaling bit = 2
> * threshold = 1815/2016 blocks (90%)
>
> For the extended lockin period, I propose 14112 blocks, which is 7
> retarget periods. Thus the earliest activation height will be 697536 and
> the latest activation height will be 709632.
>
> This will give us an approximate start time of May 1st 2021 and an
> approximate timeout time of August 7th 2021, for a total activation
> period of just over 3 months. The extended lockin period is the same
> number of blocks as the activation period so that will also be just over
> 3 months, giving us the latest activation time of November 13th, 2021.
> If miners activated as soon as possible, the earliest activation time
> would be August 21st 2021.
>
> Additionally, this timeline assumes a mid-April release of Bitcoin Core
> 0.21.1 containing these parameters. They could be changed to move up if
> the expected release date were sooner.
>
>
> Andrew Chow
>
> On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
> > On the ##taproot-activation IRC channel, Russell O'Connor recently
> > proposed a modification of the "Let's see what happens" activation
> > proposal.[1] The idea received significant discussion and seemed
> > acceptable to several people who could not previously agree on a
> > proposal (although this doesn't necessarily make it their first
> > choice).  The following is my attempt at a description.
> >
> > 1. Start soon: shortly after the release of software containing this
> >     proposed activation logic, nodes will begin counting blocks towards
> >     the 90% threshold required to lock in taproot.[2]
> >
> > 2. Stop soon: if the lockin threshold isn't reached within approximately
> >     three months, the activation attempt fails.  There is no mandatory
> >     activation and everyone is encouraged to try again using different
> >     activation parameters.
> >
> > 2. Delayed activation: in the happy occasion where the lockin threshold
> >     is reached, taproot is guaranteed to eventually activate---but not
> >     until approximately six months after signal tracking started.
> >
> > ## Example timeline
> >
> > (All dates approximate; see the section below about BIP9 vs BIP8.)
> >
> > - T+0: release of one or more full nodes with activation code
> > - T+14: signal tracking begins
> > - T+28: earliest possible lock in
> > - T+104: locked in by this date or need to try a different activation
> process
> > - T+194: activation (if lockin occurred)
> >
> > ## Analysis
> >
> > The goal of Speedy Trial is to allow a taproot activation attempt to
> > either quickly succeed or quickly fail---without compromising safety in
> > either case.  Details below:
> >
> > ### Mitigating the problems of early success
> >
> > New rules added in a soft fork need to be enforced by a large part of
> > the economy or there's a risk that a long chain of blocks breaking the
> > rules will be accepted by some users and rejected by others, causing a
> > chain split that can result in large direct losses to transaction
> > receivers and potentially even larger indirect losses to holders due to
> > reduced confidence in the safety of the Bitcoin system.
> >
> > One step developers have taken in the past to ensure widespread adoption
> > of new consensus rules is programming in a delay between the time
> software
> > with those rules is expected to be released and when the software starts
> > tracking which blocks signal for activation.  For example:
> >
> >      Soft fork        | Release    | Start      | Delta
> >      -----------------+------------+------------+----------
> >      BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days
> >      BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
> >
> >      Sources: BitcoinCore.org,
> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
> >
> > Speedy Trial replaces most of that upfront delay with a backend delay.
> > No matter how fast taproot's activation threshold is reached by miners,
> > there will be six months between the time signal tracking starts and when
> > nodes will begin enforcing taproot's rules.  This gives the userbase even
> > more time to upgrade than if we had used the most recently proposed start
> > date for a BIP8 activation (~July 23rd).[2]
> >
> > ### Succeed, or fail fast
> >
> > The earlier version of this proposal was documented over 200 days ago[3]
> > and taproot's underlying code was merged into Bitcoin Core over 140 days
> > ago.[4]  If we had started Speedy Trial at the time taproot
> > was merged (which is a bit unrealistic), we would've either be less than
> > two months away from having taproot or we would have moved on to the
> > next activation attempt over a month ago.
> >
> > Instead, we've debated at length and don't appear to be any closer to
> > what I think is a widely acceptable solution than when the mailing list
> > began discussing post-segwit activation schemes over a year ago.[5]  I
> > think Speedy Trial is a way to generate fast progress that will either
> > end the debate (for now, if activation is successful) or give us some
> > actual data upon which to base future taproot activation proposals.
> >
> > Of course, for those who enjoy the debate, discussion can continue while
> > waiting for the results of Speedy Trial.
> >
> > ### Base activation protocol
> >
> > The idea can be implemented on top of either Bitcoin Core's existing
> > BIP9 code or its proposed BIP8 patchset.[6]
> >
> > - BIP9 uses two time-based[7] parameters, starttime and timeout.  Using
> >    these values plus a time-based parameter for the minimum activation
> >    delay would give three months for miners to activate taproot, but some
> >    of that time near the start or the end might not be usable due to
> >    signals only being measured in full retarget periods.  However, the
> >    six month time for users to upgrade their node would be not be
> >    affected by either slow or fast block production.
> >
> >      BIP9 is already part of Bitcoin Core and I think the changes being
> >      proposed would be relatively small, resulting in a small patch that
> >      could be easy to review.
> >
> > - BIP8 uses two height-based parameters, startheight and timeoutheight.
> >    Using height values would ensure miners had a certain number of
> >    retarget periods (6) to lock in taproot and that there'd be a certain
> >    number of blocks (about 24,000) until activation, although latest lock
> >    in and expected activation could occur moderately earlier or later
> >    than the estimated three and six months.
> >
> >      BIP8 would likely be used if Speedy Trial fails, so it could be
> >      advantageous to base this proposal on BIP8 so that we gain
> >      experience running that code in production.
> >
> > For additional discussion about using times versus heights, see today's
> > log for ##taproot-activation.[11]
> >
> > ### Additional concerns
> >
> > - Encourages false signaling: false signaling is when miners signal
> >    readiness to enforce rules that their nodes don't actually support.
> >    This was partially responsible for a six-block reorg shortly after the
> >    final BIP66 activation[8] and was found to still be a problem during
> >    the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
> >
> >    Because Speedy Trial only gives miners a maximum of three months to
> >    signal support for taproot, it may encourage such false signaling.  If
> >    taproot locks in as a result of their signaling but most of them fail
> >    to upgrade by the activation date several months later, unprepared
> >    miners could lose large amounts of money and users could see long
> >    reorgs (with unupgraded nodes and SPV lite clients potentially losing
> >    money).
> >
> >    Compared to other activation proposals, I think the only difference is
> >    Speedy Trial's short timeline.  False signaling is possible with any
> >    other proposal and the same problems can occur if miners fail to
> >    upgrade for any mandatory activation.
> >
> > ### Additional advantages
> >
> > - No mandatory signaling: at no time are miners required to signal by
> >    Speedy Trial.  This includes no mandatory signaling during the
> >    locked_in period(s), although such signaling will be encouraged (as it
> >    was with BIP9[10]).
> >
> > - Party time: to a lesser degree, a benefit mentioned for flag day
> >    activation may also apply here: we could get up to six months
> >    advanced notice of taproot activation, allowing users, developers, and
> >    organizations to prepare software, announcements, and celebrations for
> >    that event.
> >
> > ## Implementation details and next steps
> >
> > Initial discussion about implementation may be found in today's
> > ##taproot-activation log.[11] If it appears Speedy Trial may have
> > traction, Russell O'Connor has offered to work on a patch against BIP8
> > implementing it.
> >
> > ## Acknowledgments
> >
> > The original idea for a short-duration attempt was discussed in the
> > ##taproot-activation IRC channel last July and the revised idea saw
> > additional evaluation there this week.  Despite growing frustration,
> > discussion has been overwhelmingly constructive, for which all the
> > contributors should be commended.  Although this should not in any way
> > imply endorsement, I'm grateful for the review and comments on a draft
> > of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
> > Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
> > O'Connor, and IRC users maybehuman and proofofkeags
> >
> > ## Footnotes
> >
> > [1]
> https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
> >
> > [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
> >      seemed to have near-universal support during the 2021-02-16 IRC
> >      meeting.  See:
> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
> >
> > [3]
> https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldid=68062
> >
> > [4] https://github.com/bitcoin/bitcoin/pull/19953
> >
> > [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
> >
> > [6] https://github.com/bitcoin/bitcoin/pull/19573
> >
> > [7] BIP9's times are based on the median of the past 11 blocks, which
> >      usually trails UTC by about 90 minutes but which can trail behind
> >      realtime significantly if miners are doing weird things.
> >
> > [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
> >
> > [9]
> https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
> >
> > [10]
> https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339
> >
> > [11] http://gnusha.org/taproot-activation/2021-03-05.log
> > _______________________________________________
> > 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
>

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

<div dir=3D"ltr"><div>Hi Andrew,</div><div><br></div><div>This is a slight =
misunderstanding of the proposal.=C2=A0 Rather than an extended lockin peri=
od (a term I&#39;ve erroneously used in the past) it is really a minimum ac=
tivation height.</div><div><br></div><div>Thus using your figures it would =
instead be:</div><div><br></div><div>* start height =3D 681408 /* about May=
 1st */<br>
* timeout height =3D 695520 /* about Aug 7th */<br></div><div>* min activat=
ion height =3D 709632 /* about Nov 13th */<br></div><div>
* lockinontimeout =3D False<br>
* signaling bit =3D 2<br>
* threshold =3D 1815/2016 blocks (90%)</div><div><br></div><div>This guaran=
tees 7 retargeting periods between start height and timeout height.</div><d=
iv><br></div><div>Being able to make a guarantee about how many retargeting=
 periods we get is perhaps something worth pursuing given that the signalin=
g period is so short for this trial.<br></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 6, 2021 at 1:04 AM Andr=
ew Chow via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">I like this idea.<br>
<br>
In terms of actual parameters, I propose that we base this Speedy Trial<br>
off of BIP 8 with the following parameters:<br>
* start height =3D 681408<br>
* timeout height =3D 695520<br>
* lockinontimeout =3D False<br>
* signaling bit =3D 2<br>
* threshold =3D 1815/2016 blocks (90%)<br>
<br>
For the extended lockin period, I propose 14112 blocks, which is 7<br>
retarget periods. Thus the earliest activation height will be 697536 and<br=
>
the latest activation height will be 709632.<br>
<br>
This will give us an approximate start time of May 1st 2021 and an<br>
approximate timeout time of August 7th 2021, for a total activation<br>
period of just over 3 months. The extended lockin period is the same<br>
number of blocks as the activation period so that will also be just over<br=
>
3 months, giving us the latest activation time of November 13th, 2021.<br>
If miners activated as soon as possible, the earliest activation time<br>
would be August 21st 2021.<br>
<br>
Additionally, this timeline assumes a mid-April release of Bitcoin Core<br>
0.21.1 containing these parameters. They could be changed to move up if<br>
the expected release date were sooner.<br>
<br>
<br>
Andrew Chow<br>
<br>
On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:<br>
&gt; On the ##taproot-activation IRC channel, Russell O&#39;Connor recently=
<br>
&gt; proposed a modification of the &quot;Let&#39;s see what happens&quot; =
activation<br>
&gt; proposal.[1] The idea received significant discussion and seemed<br>
&gt; acceptable to several people who could not previously agree on a<br>
&gt; proposal (although this doesn&#39;t necessarily make it their first<br=
>
&gt; choice).=C2=A0 The following is my attempt at a description.<br>
&gt;<br>
&gt; 1. Start soon: shortly after the release of software containing this<b=
r>
&gt;=C2=A0 =C2=A0 =C2=A0proposed activation logic, nodes will begin countin=
g blocks towards<br>
&gt;=C2=A0 =C2=A0 =C2=A0the 90% threshold required to lock in taproot.[2]<b=
r>
&gt;<br>
&gt; 2. Stop soon: if the lockin threshold isn&#39;t reached within approxi=
mately<br>
&gt;=C2=A0 =C2=A0 =C2=A0three months, the activation attempt fails.=C2=A0 T=
here is no mandatory<br>
&gt;=C2=A0 =C2=A0 =C2=A0activation and everyone is encouraged to try again =
using different<br>
&gt;=C2=A0 =C2=A0 =C2=A0activation parameters.<br>
&gt;<br>
&gt; 2. Delayed activation: in the happy occasion where the lockin threshol=
d<br>
&gt;=C2=A0 =C2=A0 =C2=A0is reached, taproot is guaranteed to eventually act=
ivate---but not<br>
&gt;=C2=A0 =C2=A0 =C2=A0until approximately six months after signal trackin=
g started.<br>
&gt;<br>
&gt; ## Example timeline<br>
&gt;<br>
&gt; (All dates approximate; see the section below about BIP9 vs BIP8.)<br>
&gt;<br>
&gt; - T+0: release of one or more full nodes with activation code<br>
&gt; - T+14: signal tracking begins<br>
&gt; - T+28: earliest possible lock in<br>
&gt; - T+104: locked in by this date or need to try a different activation =
process<br>
&gt; - T+194: activation (if lockin occurred)<br>
&gt;<br>
&gt; ## Analysis<br>
&gt;<br>
&gt; The goal of Speedy Trial is to allow a taproot activation attempt to<b=
r>
&gt; either quickly succeed or quickly fail---without compromising safety i=
n<br>
&gt; either case.=C2=A0 Details below:<br>
&gt;<br>
&gt; ### Mitigating the problems of early success<br>
&gt;<br>
&gt; New rules added in a soft fork need to be enforced by a large part of<=
br>
&gt; the economy or there&#39;s a risk that a long chain of blocks breaking=
 the<br>
&gt; rules will be accepted by some users and rejected by others, causing a=
<br>
&gt; chain split that can result in large direct losses to transaction<br>
&gt; receivers and potentially even larger indirect losses to holders due t=
o<br>
&gt; reduced confidence in the safety of the Bitcoin system.<br>
&gt;<br>
&gt; One step developers have taken in the past to ensure widespread adopti=
on<br>
&gt; of new consensus rules is programming in a delay between the time soft=
ware<br>
&gt; with those rules is expected to be released and when the software star=
ts<br>
&gt; tracking which blocks signal for activation.=C2=A0 For example:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 Soft fork=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Release=C2=
=A0 =C2=A0 | Start=C2=A0 =C2=A0 =C2=A0 | Delta<br>
&gt;=C2=A0 =C2=A0 =C2=A0 -----------------+------------+------------+------=
----<br>
&gt;=C2=A0 =C2=A0 =C2=A0 BIP68 (v0.12.1)=C2=A0 | 2016-04-15 | 2016-05-11 | =
26 days<br>
&gt;=C2=A0 =C2=A0 =C2=A0 BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 da=
ys<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 Sources: BitcoinCore.org, <a href=3D"https://gist.=
github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc" rel=3D"noreferrer" tar=
get=3D"_blank">https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c8=
17bc</a><br>
&gt;<br>
&gt; Speedy Trial replaces most of that upfront delay with a backend delay.=
<br>
&gt; No matter how fast taproot&#39;s activation threshold is reached by mi=
ners,<br>
&gt; there will be six months between the time signal tracking starts and w=
hen<br>
&gt; nodes will begin enforcing taproot&#39;s rules.=C2=A0 This gives the u=
serbase even<br>
&gt; more time to upgrade than if we had used the most recently proposed st=
art<br>
&gt; date for a BIP8 activation (~July 23rd).[2]<br>
&gt;<br>
&gt; ### Succeed, or fail fast<br>
&gt;<br>
&gt; The earlier version of this proposal was documented over 200 days ago[=
3]<br>
&gt; and taproot&#39;s underlying code was merged into Bitcoin Core over 14=
0 days<br>
&gt; ago.[4]=C2=A0 If we had started Speedy Trial at the time taproot<br>
&gt; was merged (which is a bit unrealistic), we would&#39;ve either be les=
s than<br>
&gt; two months away from having taproot or we would have moved on to the<b=
r>
&gt; next activation attempt over a month ago.<br>
&gt;<br>
&gt; Instead, we&#39;ve debated at length and don&#39;t appear to be any cl=
oser to<br>
&gt; what I think is a widely acceptable solution than when the mailing lis=
t<br>
&gt; began discussing post-segwit activation schemes over a year ago.[5]=C2=
=A0 I<br>
&gt; think Speedy Trial is a way to generate fast progress that will either=
<br>
&gt; end the debate (for now, if activation is successful) or give us some<=
br>
&gt; actual data upon which to base future taproot activation proposals.<br=
>
&gt;<br>
&gt; Of course, for those who enjoy the debate, discussion can continue whi=
le<br>
&gt; waiting for the results of Speedy Trial.<br>
&gt;<br>
&gt; ### Base activation protocol<br>
&gt;<br>
&gt; The idea can be implemented on top of either Bitcoin Core&#39;s existi=
ng<br>
&gt; BIP9 code or its proposed BIP8 patchset.[6]<br>
&gt;<br>
&gt; - BIP9 uses two time-based[7] parameters, starttime and timeout.=C2=A0=
 Using<br>
&gt;=C2=A0 =C2=A0 these values plus a time-based parameter for the minimum =
activation<br>
&gt;=C2=A0 =C2=A0 delay would give three months for miners to activate tapr=
oot, but some<br>
&gt;=C2=A0 =C2=A0 of that time near the start or the end might not be usabl=
e due to<br>
&gt;=C2=A0 =C2=A0 signals only being measured in full retarget periods.=C2=
=A0 However, the<br>
&gt;=C2=A0 =C2=A0 six month time for users to upgrade their node would be n=
ot be<br>
&gt;=C2=A0 =C2=A0 affected by either slow or fast block production.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 BIP9 is already part of Bitcoin Core and I think t=
he changes being<br>
&gt;=C2=A0 =C2=A0 =C2=A0 proposed would be relatively small, resulting in a=
 small patch that<br>
&gt;=C2=A0 =C2=A0 =C2=A0 could be easy to review.<br>
&gt;<br>
&gt; - BIP8 uses two height-based parameters, startheight and timeoutheight=
.<br>
&gt;=C2=A0 =C2=A0 Using height values would ensure miners had a certain num=
ber of<br>
&gt;=C2=A0 =C2=A0 retarget periods (6) to lock in taproot and that there&#3=
9;d be a certain<br>
&gt;=C2=A0 =C2=A0 number of blocks (about 24,000) until activation, althoug=
h latest lock<br>
&gt;=C2=A0 =C2=A0 in and expected activation could occur moderately earlier=
 or later<br>
&gt;=C2=A0 =C2=A0 than the estimated three and six months.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 BIP8 would likely be used if Speedy Trial fails, s=
o it could be<br>
&gt;=C2=A0 =C2=A0 =C2=A0 advantageous to base this proposal on BIP8 so that=
 we gain<br>
&gt;=C2=A0 =C2=A0 =C2=A0 experience running that code in production.<br>
&gt;<br>
&gt; For additional discussion about using times versus heights, see today&=
#39;s<br>
&gt; log for ##taproot-activation.[11]<br>
&gt;<br>
&gt; ### Additional concerns<br>
&gt;<br>
&gt; - Encourages false signaling: false signaling is when miners signal<br=
>
&gt;=C2=A0 =C2=A0 readiness to enforce rules that their nodes don&#39;t act=
ually support.<br>
&gt;=C2=A0 =C2=A0 This was partially responsible for a six-block reorg shor=
tly after the<br>
&gt;=C2=A0 =C2=A0 final BIP66 activation[8] and was found to still be a pro=
blem during<br>
&gt;=C2=A0 =C2=A0 the BIP68 lockin period despite BIP9 being designed to av=
oid it.[9]<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 Because Speedy Trial only gives miners a maximum of three=
 months to<br>
&gt;=C2=A0 =C2=A0 signal support for taproot, it may encourage such false s=
ignaling.=C2=A0 If<br>
&gt;=C2=A0 =C2=A0 taproot locks in as a result of their signaling but most =
of them fail<br>
&gt;=C2=A0 =C2=A0 to upgrade by the activation date several months later, u=
nprepared<br>
&gt;=C2=A0 =C2=A0 miners could lose large amounts of money and users could =
see long<br>
&gt;=C2=A0 =C2=A0 reorgs (with unupgraded nodes and SPV lite clients potent=
ially losing<br>
&gt;=C2=A0 =C2=A0 money).<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 Compared to other activation proposals, I think the only =
difference is<br>
&gt;=C2=A0 =C2=A0 Speedy Trial&#39;s short timeline.=C2=A0 False signaling =
is possible with any<br>
&gt;=C2=A0 =C2=A0 other proposal and the same problems can occur if miners =
fail to<br>
&gt;=C2=A0 =C2=A0 upgrade for any mandatory activation.<br>
&gt;<br>
&gt; ### Additional advantages<br>
&gt;<br>
&gt; - No mandatory signaling: at no time are miners required to signal by<=
br>
&gt;=C2=A0 =C2=A0 Speedy Trial.=C2=A0 This includes no mandatory signaling =
during the<br>
&gt;=C2=A0 =C2=A0 locked_in period(s), although such signaling will be enco=
uraged (as it<br>
&gt;=C2=A0 =C2=A0 was with BIP9[10]).<br>
&gt;<br>
&gt; - Party time: to a lesser degree, a benefit mentioned for flag day<br>
&gt;=C2=A0 =C2=A0 activation may also apply here: we could get up to six mo=
nths<br>
&gt;=C2=A0 =C2=A0 advanced notice of taproot activation, allowing users, de=
velopers, and<br>
&gt;=C2=A0 =C2=A0 organizations to prepare software, announcements, and cel=
ebrations for<br>
&gt;=C2=A0 =C2=A0 that event.<br>
&gt;<br>
&gt; ## Implementation details and next steps<br>
&gt;<br>
&gt; Initial discussion about implementation may be found in today&#39;s<br=
>
&gt; ##taproot-activation log.[11] If it appears Speedy Trial may have<br>
&gt; traction, Russell O&#39;Connor has offered to work on a patch against =
BIP8<br>
&gt; implementing it.<br>
&gt;<br>
&gt; ## Acknowledgments<br>
&gt;<br>
&gt; The original idea for a short-duration attempt was discussed in the<br=
>
&gt; ##taproot-activation IRC channel last July and the revised idea saw<br=
>
&gt; additional evaluation there this week.=C2=A0 Despite growing frustrati=
on,<br>
&gt; discussion has been overwhelmingly constructive, for which all the<br>
&gt; contributors should be commended.=C2=A0 Although this should not in an=
y way<br>
&gt; imply endorsement, I&#39;m grateful for the review and comments on a d=
raft<br>
&gt; of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belche=
r,<br>
&gt; Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell<br>
&gt; O&#39;Connor, and IRC users maybehuman and proofofkeags<br>
&gt;<br>
&gt; ## Footnotes<br>
&gt;<br>
&gt; [1] <a href=3D"https://en.bitcoin.it/wiki/Taproot_activation_proposals=
#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29" rel=3D"noreferrer=
" target=3D"_blank">https://en.bitcoin.it/wiki/Taproot_activation_proposals=
#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29</a><br>
&gt;<br>
&gt; [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget perio=
d<br>
&gt;=C2=A0 =C2=A0 =C2=A0 seemed to have near-universal support during the 2=
021-02-16 IRC<br>
&gt;=C2=A0 =C2=A0 =C2=A0 meeting.=C2=A0 See: <a href=3D"https://en.bitcoin.=
it/wiki/Taproot_activation_proposal_202102" rel=3D"noreferrer" target=3D"_b=
lank">https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102</a><br>
&gt;<br>
&gt; [3] <a href=3D"https://en.bitcoin.it/w/index.php?title=3DTaproot_activ=
ation_proposals&amp;oldid=3D68062" rel=3D"noreferrer" target=3D"_blank">htt=
ps://en.bitcoin.it/w/index.php?title=3DTaproot_activation_proposals&amp;old=
id=3D68062</a><br>
&gt;<br>
&gt; [4] <a href=3D"https://github.com/bitcoin/bitcoin/pull/19953" rel=3D"n=
oreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19953<=
/a><br>
&gt;<br>
&gt; [5] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2020-January/017547.html" rel=3D"noreferrer" target=3D"_blank">https://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html</a><b=
r>
&gt;<br>
&gt; [6] <a href=3D"https://github.com/bitcoin/bitcoin/pull/19573" rel=3D"n=
oreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19573<=
/a><br>
&gt;<br>
&gt; [7] BIP9&#39;s times are based on the median of the past 11 blocks, wh=
ich<br>
&gt;=C2=A0 =C2=A0 =C2=A0 usually trails UTC by about 90 minutes but which c=
an trail behind<br>
&gt;=C2=A0 =C2=A0 =C2=A0 realtime significantly if miners are doing weird t=
hings.<br>
&gt;<br>
&gt; [8] <a href=3D"https://en.bitcoin.it/wiki/July_2015_chain_forks" rel=
=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/July_2015_chai=
n_forks</a><br>
&gt;<br>
&gt; [9] <a href=3D"https://buildingbitcoin.org/bitcoin-core-dev/log-2016-0=
6-21.html#l-32" rel=3D"noreferrer" target=3D"_blank">https://buildingbitcoi=
n.org/bitcoin-core-dev/log-2016-06-21.html#l-32</a><br>
&gt;<br>
&gt; [10] <a href=3D"https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba=
583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339" rel=3D=
"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/ed25=
cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L3=
39</a><br>
&gt;<br>
&gt; [11] <a href=3D"http://gnusha.org/taproot-activation/2021-03-05.log" r=
el=3D"noreferrer" target=3D"_blank">http://gnusha.org/taproot-activation/20=
21-03-05.log</a><br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000007b0f6d05bcdf3e6b--