From: Jeremy <jlrubin@mit•edu>
To: Anthony Towns <aj@erisian•com.au>
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
Date: Mon, 5 Apr 2021 21:18:52 -0700 [thread overview]
Message-ID: <CAD5xwhgjMPy=5oQ3G-wL08V_N4Z_igNy9GFa4B2mzJtMZNxgxg@mail.gmail.com> (raw)
In-Reply-To: <20210405103452.GA15866@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 6721 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 10567 bytes --]
next prev parent reply other threads:[~2021-04-06 4:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-04 4:39 Jeremy
2021-04-04 9:31 ` Jorge Timón
2021-04-04 22:00 ` Robert Spigler
2021-04-05 10:34 ` Anthony Towns
2021-04-06 4:18 ` Jeremy [this message]
2021-04-06 14:34 ` Russell O'Connor
2021-04-06 14:51 ` Adam Back
2021-04-06 16:22 ` David A. Harding
2021-04-06 16:27 ` Russell O'Connor
2021-04-06 17:17 ` Russell O'Connor
2021-04-06 19:48 ` Anthony Towns
2021-04-06 21:31 ` David A. Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD5xwhgjMPy=5oQ3G-wL08V_N4Z_igNy9GFa4B2mzJtMZNxgxg@mail.gmail.com' \
--to=jlrubin@mit$(echo .)edu \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox