path: root/ca/062a82a31a05815023ffb061a88fb35af70c14

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 94E94C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Apr 2021 04:19:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 6ECD1605C8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Apr 2021 04:19:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 93pUsJ_rCEiz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Apr 2021 04:19:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 95A6B605AC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Apr 2021 04:19:06 +0000 (UTC)
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com
 [209.85.166.42]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1364J42D003176
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 6 Apr 2021 00:19:05 -0400
Received: by mail-io1-f42.google.com with SMTP id j26so9002873iog.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Apr 2021 21:19:05 -0700 (PDT)
X-Gm-Message-State: AOAM531jHCIoxlYHPy6HsDyiaesp5cKaQiubjRXXoWY/BJXkwXlfj1bV
 nCSnU2q0/S9y6pAB7Ch3JC2ryIVUlAQOLw4+nm8=
X-Google-Smtp-Source: ABdhPJyo9HmmQLmPEvlzAjsj2aqYE+s9ynYva4VuPssElBBTuzjjz0jC5JaITeS0g5I5GGw5KumL81vmUHtnyz8c80A=
X-Received: by 2002:a02:ccb2:: with SMTP id t18mr27042783jap.123.1617682744436; 
 Mon, 05 Apr 2021 21:19:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgTKLhA82=PsF9EXrhvmx6zcA=ffOvHD4qt4q1sAqzhng@mail.gmail.com>
 <20210405103452.GA15866@erisian.com.au>
In-Reply-To: <20210405103452.GA15866@erisian.com.au>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 5 Apr 2021 21:18:52 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgjMPy=5oQ3G-wL08V_N4Z_igNy9GFa4B2mzJtMZNxgxg@mail.gmail.com>
Message-ID: <CAD5xwhgjMPy=5oQ3G-wL08V_N4Z_igNy9GFa4B2mzJtMZNxgxg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000576ecf05bf461da4"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th
 19:00 UTC bitcoin/bitcoin-dev
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: Tue, 06 Apr 2021 04:19:08 -0000

--000000000000576ecf05bf461da4
Content-Type: text/plain; charset="UTF-8"

I found the "50% chance of activating" a bit confusing of a watermark, so I
asked AJ if he didn't mind producing and tabulating the 10% chance, 50%
chance, and 90% chance to show the sharpness of the bounds better. Each
category below shows the single-shot and repeated trial odds for the range
of trials (5 to 7). Additionally, I ran the 99% & 1% band to show that
we're likely to not have a false positive if < 87% is signalling nor a
false negative if > 90% is signalling

1%:
    87.61% hashpower gives 0.20188% chance of success for 0.01005% chance
over 5 trials
    87.47% hashpower gives 0.14044% chance of success for 0.00979% chance
over 7 trials
    86.74% hashpower gives 0.01929% chance of success for 0.00979% chance
over 51 trials
    86.74% hashpower gives 0.02080% chance of success for 0.01138% chance
over 55 trials


99%:
    89.34% hashpower gives 60.19226% chance of success for 0.99000% chance
over 5 trials
    89.08% hashpower gives 48.20380% chance of success for 0.99000% chance
over 7 trials

    87.94% hashpower gives 8.63591% chance of success for 0.99001% chance
over 51 trials
    87.90% hashpower gives 8.03152% chance of success for 0.99000% chance
over 55 trials


I was also curious to see what hashrate we'd need to have the classic 5 9's
of reliability if we were to only have *two* periods to signal. This serves
a decent check for the situation where the earlier periods in a ST should
be discounted (i.e., P(signals> 90% | first 3 periods) = 0) because miners
still need time to upgrade.

91.03% hashpower gives 99.68578% chance of success for 0.99999% chance over
2 trials

I believe this demonstrates more strongly that MTP can be used to ensure a
smooth upgrade.

------------------------


Should've been 1815, and seems like I had some older code that deals
with precision better, so:

10%:
   88.15% gives 2.08538% chance of success for 0.10001% chance over 5 trials
   87.98% gives 1.49100% chance of success for 0.09982% chance over 7 trials

   87.16% gives 0.20610% chance of success for 0.09987% chance over 51
trials
   87.13% gives 0.18834% chance of success for 0.09849% chance over 55
trials

50%:
   88.67% gives 12.94200% chance of success for 0.49992% chance over 5
trials
   88.47% gives 9.42506% chance of success for 0.49990% chance over 7 trials

   87.53% gives 1.35127% chance of success for 0.50035% chance over 51
trials
   87.50% gives 1.25229% chance of success for 0.49998% chance over 55
trials

90%:
   89.07% gives 36.90722% chance of success for 0.90002% chance over 5
trials
   88.83% gives 28.02839% chance of success for 0.89997% chance over 7
trials

   87.78% gives 4.41568% chance of success for 0.90006% chance over 51
trials
   87.75% gives 4.09983% chance of success for 0.89999% chance over 55
trials

So 0.24% is the biggest difference for 5-7 trials at 90%, but the entire
range is under 2% anyway (87.13% for 55 trials to get 10% vs 89.07%
for 5 trials to get 90%).

Note, each "trial" is a retarget period here...

Code:
https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-repeated_trials-py

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Mon, Apr 5, 2021 at 3:35 AM Anthony Towns <aj@erisian.com.au> wrote:

> On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:
> > As such, the main conversation in this agenda item is
> > around the pros/cons of height or MTP and determining if we can reach
> consensus
> > on either approach.
>
> Here's some numbers.
>
> Given a desired signalling period of xxx days, where signaling begins
> on the first retarget boundary after the starttime and ends on the last
> retarget boundary before the endtime, this is how many retarget periods
> you get (based on blocks since 2015-01-01):
>
>  90 days: mainnet  5-7 full 2016-block retarget periods
> 180 days: mainnet 11-14
> 365 days: mainnet 25-27
> 730 days: mainnet 51-55
>
> (This applies to non-signalling periods like the activation/lock in delay
> too of course. If you change it so that it ends at the first retarget
> period after endtime, all the values just get incremented -- ie, 6-8,
> 12-15 etc)
>
> If I've got the maths right, then requiring 1814 of 2016 blocks to signal,
> means that having 7 periods instead of 5 lets you get a 50% chance of
> successful activation by maintaining 89.04% of hashpower over the entire
> period instead of 89.17%, while 55 periods instead of 51 gives you a 50%
> chance of success with 88.38% hashpower instead of 88.40% hashpower.
> So the "repeated trials" part doesn't look like it has any significant
> effect on mainnet.
>
> If you target yy periods instead of xxx days, starting and ending on a
> retarget boundary, you get the following stats from the last few years
> of mainnet (again starting at 2015-01-01):
>
>  1 period:  mainnet 11-17 days (range 5.2 days)
>  7 periods: mainnet 87-103 days (range 15.4 days)
> 13 periods: mainnet 166-185 days (range 17.9 days)
> 27 periods: mainnet 352-377 days (range 24.4 days)
> 54 periods: mainnet 711-747 days (range 35.0 days)
>
> As far as I can see the questions that matter are:
>
>  * is signalling still possible by the time enough miners have upgraded
>    and are ready to start signalling?
>
>  * have nodes upgraded to enforce the new rules by the time activation
>    occurs, if it occurs?
>
> But both those benefit from less real time variance, rather than less
> variance in the numbers of signalling periods, at least in every way
> that I can think of.
>
> Corresponding numbers for testnet:
>
>  90 days: testnet   5-85
> 180 days: testnet  23-131
> 365 days: testnet  70-224
> 730 days: testnet 176-390
>
> (A 50% chance of activating within 5 periods requires sustaining 89.18%
> hashpower; within 85 periods, 88.26% hashpower; far smaller differences
> with all the other ranges -- of course, presumably the only way the
> higher block rates ever actually happen is by someone pointing an ASIC at
> testnet, and thus controlling 100% of blocks for multiple periods anyway)
>
>   1 period:  testnet 5.6minutes-26 days (range 26.5 days)
>  13 periods: testnet 1-135 days (range 133.5 days)
>  27 periods: testnet 13-192 days (range 178.3 days)
>  54 periods: testnet 39-283 days (range 243.1 days)
> 100 periods: testnet 114-476 days (range 360.9 days)
>              (this is the value used in [0] in order to ensure 3 months'
>               worth of signalling is available)
> 132 periods: testnet 184-583 days (range 398.1 days)
> 225 periods: testnet 365-877 days (range 510.7 days)
> 390 periods: testnet 725-1403 days (range 677.1 days)
>
> [0] https://github.com/bitcoin/bips/pull/1081#pullrequestreview-621934640
>
> Cheers,
> aj
>
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">I found the &quot;50% cha=
nce of activating&quot; a bit confusing of a watermark, so I asked AJ if he=
 didn&#39;t mind producing and tabulating the 10% chance, 50% chance, and 9=
0% chance to show the sharpness of the bounds better. Each category below s=
hows the single-shot and repeated trial odds for the range of trials (5 to =
7). Additionally, I ran the 99% &amp; 1% band to show that we&#39;re likely=
 to not have a false positive if &lt; 87% is signalling nor a false negativ=
e if &gt; 90% is signalling<br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000">1%:</div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000">=C2=A0 =C2=A0 87.61% hashpower gives 0.20188% chance of success for 0.=
01005% chance over 5 trials<br>=C2=A0 =C2=A0 87.47% hashpower gives 0.14044=
% chance of success for 0.00979% chance over 7 trials<br>=C2=A0 =C2=A0 86.7=
4% hashpower gives 0.01929% chance of success for 0.00979% chance over 51 t=
rials<br>=C2=A0 =C2=A0 86.74% hashpower gives 0.02080% chance of success fo=
r 0.01138% chance over 55 trials<span style=3D"font-family:monospace"><br>
<br><br></span></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000">99%:<br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">=C2=A0=C2=A0=C2=A0 89.34% hashpower gives 60.1922=
6% chance of success for 0.99000% chance over 5 trials<br>=C2=A0=C2=A0=C2=
=A0 89.08% hashpower gives 48.20380% chance of success for 0.99000% chance =
over 7 trials</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000">=C2=A0=C2=A0=C2=A0 87.94% hashpower gives 8.63591% chan=
ce of success for 0.99001% chance over 51 trials<br>=C2=A0=C2=A0=C2=A0 87.9=
0% hashpower gives 8.03152% chance of success for 0.99000% chance over 55 t=
rials<span style=3D"font-family:monospace"><br><br></span></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I was als=
o curious to see what hashrate we&#39;d need to have the classic 5 9&#39;s =
of reliability if we were to only have *two* periods to signal. This serves=
 a decent check for the situation where the earlier periods in a ST should =
be discounted (i.e., P(signals&gt; 90% | first 3 periods) =3D 0) because mi=
ners still need time to upgrade.<br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000">91.03% hashpower gives 99.68578%=
 chance of success for 0.99999% chance over 2 trials<span style=3D"font-fam=
ily:monospace"><br>
</span></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">I believe this demonstrates more strongly that MTP can be use=
d to ensure a smooth upgrade.<span style=3D"font-family:monospace"><br></sp=
an></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000">------------------------<br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">Should&#39;ve been 1815, and seems like I had some older code =
that deals<br>
with precision better, so:<br>
<br>
10%:<br>
=C2=A0 =C2=A088.15% gives 2.08538% chance of success for 0.10001% chance ov=
er 5 trials<br>
=C2=A0 =C2=A087.98% gives 1.49100% chance of success for 0.09982% chance ov=
er 7 trials<br>
<br>
=C2=A0 =C2=A087.16% gives 0.20610% chance of success for 0.09987% chance ov=
er 51 trials<br>
=C2=A0 =C2=A087.13% gives 0.18834% chance of success for 0.09849% chance ov=
er 55 trials<br>
<br>
50%:<br>
=C2=A0 =C2=A088.67% gives 12.94200% chance of success for 0.49992% chance o=
ver 5 trials<br>
=C2=A0 =C2=A088.47% gives 9.42506% chance of success for 0.49990% chance ov=
er 7 trials<br>
<br>
=C2=A0 =C2=A087.53% gives 1.35127% chance of success for 0.50035% chance ov=
er 51 trials<br>
=C2=A0 =C2=A087.50% gives 1.25229% chance of success for 0.49998% chance ov=
er 55 trials<br>
<br>
90%:<br>
=C2=A0 =C2=A089.07% gives 36.90722% chance of success for 0.90002% chance o=
ver 5 trials<br>
=C2=A0 =C2=A088.83% gives 28.02839% chance of success for 0.89997% chance o=
ver 7 trials<br>
<br>
=C2=A0 =C2=A087.78% gives 4.41568% chance of success for 0.90006% chance ov=
er 51 trials<br>
=C2=A0 =C2=A087.75% gives 4.09983% chance of success for 0.89999% chance ov=
er 55 trials</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:#000000"><br>
So 0.24% is the biggest difference for 5-7 trials at 90%, but the entire<br=
>
range is under 2% anyway (87.13% for 55 trials to get 10% vs 89.07%<br>
for 5 trials to get 90%).<br>
<br>
Note, each &quot;trial&quot; is a retarget period here...<br>
<br>
Code: <a href=3D"https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a=
04ff69#file-repeated_trials-py" rel=3D"noreferrer" target=3D"_blank">https:=
//gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-repeated_tr=
ials-py</a><br>
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000"><br clear=3D"all"></div><div><div di=
r=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div=
 dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_b=
lank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D=
"_blank"></a></div></div></div><br></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 5, 2021 at 3:35 AM Anthony T=
owns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wro=
te:<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">On Sat, Apr =
03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:<br>
&gt; As such, the main conversation in this agenda item is<br>
&gt; around the pros/cons of height or MTP and determining if we can reach =
consensus<br>
&gt; on either approach.<br>
<br>
Here&#39;s some numbers.<br>
<br>
Given a desired signalling period of xxx days, where signaling begins<br>
on the first retarget boundary after the starttime and ends on the last<br>
retarget boundary before the endtime, this is how many retarget periods<br>
you get (based on blocks since 2015-01-01):<br>
<br>
=C2=A090 days: mainnet=C2=A0 5-7 full 2016-block retarget periods<br>
180 days: mainnet 11-14<br>
365 days: mainnet 25-27<br>
730 days: mainnet 51-55<br>
<br>
(This applies to non-signalling periods like the activation/lock in delay<b=
r>
too of course. If you change it so that it ends at the first retarget<br>
period after endtime, all the values just get incremented -- ie, 6-8,<br>
12-15 etc)<br>
<br>
If I&#39;ve got the maths right, then requiring 1814 of 2016 blocks to sign=
al,<br>
means that having 7 periods instead of 5 lets you get a 50% chance of<br>
successful activation by maintaining 89.04% of hashpower over the entire<br=
>
period instead of 89.17%, while 55 periods instead of 51 gives you a 50%<br=
>
chance of success with 88.38% hashpower instead of 88.40% hashpower.<br>
So the &quot;repeated trials&quot; part doesn&#39;t look like it has any si=
gnificant<br>
effect on mainnet.<br>
<br>
If you target yy periods instead of xxx days, starting and ending on a<br>
retarget boundary, you get the following stats from the last few years<br>
of mainnet (again starting at 2015-01-01):<br>
<br>
=C2=A01 period:=C2=A0 mainnet 11-17 days (range 5.2 days)<br>
=C2=A07 periods: mainnet 87-103 days (range 15.4 days)<br>
13 periods: mainnet 166-185 days (range 17.9 days)<br>
27 periods: mainnet 352-377 days (range 24.4 days)<br>
54 periods: mainnet 711-747 days (range 35.0 days)<br>
<br>
As far as I can see the questions that matter are:<br>
<br>
=C2=A0* is signalling still possible by the time enough miners have upgrade=
d<br>
=C2=A0 =C2=A0and are ready to start signalling?<br>
<br>
=C2=A0* have nodes upgraded to enforce the new rules by the time activation=
<br>
=C2=A0 =C2=A0occurs, if it occurs?<br>
<br>
But both those benefit from less real time variance, rather than less<br>
variance in the numbers of signalling periods, at least in every way<br>
that I can think of.<br>
<br>
Corresponding numbers for testnet:<br>
<br>
=C2=A090 days: testnet=C2=A0 =C2=A05-85<br>
180 days: testnet=C2=A0 23-131<br>
365 days: testnet=C2=A0 70-224<br>
730 days: testnet 176-390<br>
<br>
(A 50% chance of activating within 5 periods requires sustaining 89.18%<br>
hashpower; within 85 periods, 88.26% hashpower; far smaller differences<br>
with all the other ranges -- of course, presumably the only way the<br>
higher block rates ever actually happen is by someone pointing an ASIC at<b=
r>
testnet, and thus controlling 100% of blocks for multiple periods anyway)<b=
r>
<br>
=C2=A0 1 period:=C2=A0 testnet 5.6minutes-26 days (range 26.5 days)<br>
=C2=A013 periods: testnet 1-135 days (range 133.5 days)<br>
=C2=A027 periods: testnet 13-192 days (range 178.3 days)<br>
=C2=A054 periods: testnet 39-283 days (range 243.1 days)<br>
100 periods: testnet 114-476 days (range 360.9 days)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(this is the value used in =
[0] in order to ensure 3 months&#39;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 worth of signalling is ava=
ilable)<br>
132 periods: testnet 184-583 days (range 398.1 days)<br>
225 periods: testnet 365-877 days (range 510.7 days)<br>
390 periods: testnet 725-1403 days (range 677.1 days)<br>
<br>
[0] <a href=3D"https://github.com/bitcoin/bips/pull/1081#pullrequestreview-=
621934640" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/=
bips/pull/1081#pullrequestreview-621934640</a><br>
<br>
Cheers,<br>
aj<br>
<br>
</blockquote></div>

--000000000000576ecf05bf461da4--