From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 94E94C000A for ; 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 ; 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 ; 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 ; 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 ; Tue, 6 Apr 2021 00:19:05 -0400 Received: by mail-io1-f42.google.com with SMTP id j26so9002873iog.13 for ; 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: <20210405103452.GA15866@erisian.com.au> In-Reply-To: <20210405103452.GA15866@erisian.com.au> From: Jeremy Date: Mon, 5 Apr 2021 21:18:52 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="000000000000576ecf05bf461da4" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 On Mon, Apr 5, 2021 at 3:35 AM Anthony Towns 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
I found the "50% cha= nce 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 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% & 1% band to show that we're likely= to not have a false positive if < 87% is signalling nor a false negativ= e if > 90% is signalling

<= /div>
1%:
=C2=A0 =C2=A0 87.61% hashpower gives 0.20188% chance of success for 0.= 01005% chance over 5 trials
=C2=A0 =C2=A0 87.47% hashpower gives 0.14044= % chance of success for 0.00979% chance over 7 trials
=C2=A0 =C2=A0 86.7= 4% hashpower gives 0.01929% chance of success for 0.00979% chance over 51 t= rials
=C2=A0 =C2=A0 86.74% hashpower gives 0.02080% chance of success fo= r 0.01138% chance over 55 trials


99%:
=C2=A0=C2=A0=C2=A0 89.34% hashpower gives 60.1922= 6% chance of success for 0.99000% chance over 5 trials
=C2=A0=C2=A0=C2= =A0 89.08% hashpower gives 48.20380% chance of success for 0.99000% chance = over 7 trials

=C2=A0=C2=A0=C2=A0 87.94% hashpower gives 8.63591% chan= ce of success for 0.99001% chance over 51 trials
=C2=A0=C2=A0=C2=A0 87.9= 0% hashpower gives 8.03152% chance of success for 0.99000% chance over 55 t= rials


I was als= o 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) =3D 0) because mi= ners 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 use= d to ensure a smooth upgrade.

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


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

10%:
=C2=A0 =C2=A088.15% gives 2.08538% chance of success for 0.10001% chance ov= er 5 trials
=C2=A0 =C2=A087.98% gives 1.49100% chance of success for 0.09982% chance ov= er 7 trials

=C2=A0 =C2=A087.16% gives 0.20610% chance of success for 0.09987% chance ov= er 51 trials
=C2=A0 =C2=A087.13% gives 0.18834% chance of success for 0.09849% chance ov= er 55 trials

50%:
=C2=A0 =C2=A088.67% gives 12.94200% chance of success for 0.49992% chance o= ver 5 trials
=C2=A0 =C2=A088.47% gives 9.42506% chance of success for 0.49990% chance ov= er 7 trials

=C2=A0 =C2=A087.53% gives 1.35127% chance of success for 0.50035% chance ov= er 51 trials
=C2=A0 =C2=A087.50% gives 1.25229% chance of success for 0.49998% chance ov= er 55 trials

90%:
=C2=A0 =C2=A089.07% gives 36.90722% chance of success for 0.90002% chance o= ver 5 trials
=C2=A0 =C2=A088.83% gives 28.02839% chance of success for 0.89997% chance o= ver 7 trials

=C2=A0 =C2=A087.78% gives 4.41568% chance of success for 0.90006% chance ov= er 51 trials
=C2=A0 =C2=A087.75% gives 4.09983% chance of success for 0.89999% chance ov= er 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_tr= ials-py



On Mon, Apr 5, 2021 at 3:35 AM Anthony T= owns <aj@erisian.com.au> wro= te:
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):

=C2=A090 days: mainnet=C2=A0 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 sign= al,
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 si= gnificant
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):

=C2=A01 period:=C2=A0 mainnet 11-17 days (range 5.2 days)
=C2=A07 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:

=C2=A0* is signalling still possible by the time enough miners have upgrade= d
=C2=A0 =C2=A0and are ready to start signalling?

=C2=A0* have nodes upgraded to enforce the new rules by the time activation=
=C2=A0 =C2=A0occurs, 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:

=C2=A090 days: testnet=C2=A0 =C2=A05-85
180 days: testnet=C2=A0 23-131
365 days: testnet=C2=A0 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)
=C2=A0 1 period:=C2=A0 testnet 5.6minutes-26 days (range 26.5 days)
=C2=A013 periods: testnet 1-135 days (range 133.5 days)
=C2=A027 periods: testnet 13-192 days (range 178.3 days)
=C2=A054 periods: testnet 39-283 days (range 243.1 days)
100 periods: testnet 114-476 days (range 360.9 days)
=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'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 worth of signalling is ava= ilable)
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--