Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

[Jeremy <jlrubin@mit.edu>]

[-- 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 --]