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

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

[Jeremy]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

We'll be having another meeting this Tuesday, as per
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html.
If you can't make it feel free to leave a comment on any agenda item below,
or if you think there are other things to be discussed.

Agenda:

1. AJ's update to MTP time.

Please review https://github.com/bitcoin/bitcoin/pull/21377 as AJ updated
it substantially.

The PR is now purely MTP based, and the state machine has been simplified.
This approach is intended to be compatible with a mandatory signaling
period (via a LAST_CHANCE change) and makes it easier to deploy ST on
signets (irrelevant for Taproot, because it is already active on all
signets).

2. Selecting between MTP and Height

In the previous meeting, there was no substantial publicly discussed
benefit to using MTPs over height. Since agenda item 1, there is now a
tangible benefit to using MTP.

The changes AJ promulgated for MTP neutralizes the argument, mostly, that
MTP was easier to review. 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.

3. Timeline Discussion
In all hope, we will reach consensus around item 2. Should that occur, we
can use this time to discuss a final selection on parameters, mindful of
Core's process.

If the meeting doesn't reach rough consensus around item 2, it seems that
we may fall short on the proposed schedule from last time. In this section,
we can discuss realities around scheduling.


Best,

Jeremy



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

[-- Attachment #2: Type: text/html, Size: 5226 bytes --]

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

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

So the only thing that seemed clear, using height as per bip8, it's not
clear anymore.
And, as usual, we're not talking about activation in general but about
taproot activation, segwit activation...

I won't make it to the meeting because I don't think I have much more to
contribute that I haven't said already beyond perhaps: sigh.
My arguments will probably ignored again, so it doesn't matter.


On Sun, Apr 4, 2021, 06:39 Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We'll be having another meeting this Tuesday, as per
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html.
> If you can't make it feel free to leave a comment on any agenda item below,
> or if you think there are other things to be discussed.
>
> Agenda:
>
> 1. AJ's update to MTP time.
>
> Please review https://github.com/bitcoin/bitcoin/pull/21377 as AJ updated
> it substantially.
>
> The PR is now purely MTP based, and the state machine has been simplified.
> This approach is intended to be compatible with a mandatory signaling
> period (via a LAST_CHANCE change) and makes it easier to deploy ST on
> signets (irrelevant for Taproot, because it is already active on all
> signets).
>
> 2. Selecting between MTP and Height
>
> In the previous meeting, there was no substantial publicly discussed
> benefit to using MTPs over height. Since agenda item 1, there is now a
> tangible benefit to using MTP.
>
> The changes AJ promulgated for MTP neutralizes the argument, mostly, that
> MTP was easier to review. 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.
>
> 3. Timeline Discussion
> In all hope, we will reach consensus around item 2. Should that occur, we
> can use this time to discuss a final selection on parameters, mindful of
> Core's process.
>
> If the meeting doesn't reach rough consensus around item 2, it seems that
> we may fall short on the proposed schedule from last time. In this section,
> we can discuss realities around scheduling.
>
>
> Best,
>
> Jeremy
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6573 bytes --]

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

[Robert Spigler]

[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]

I'd like to pre-register a comment that I don't think signet should be a consideration for MTP vs height, since taproot is already activated on signet, and there's no indication that ST will be used in the future (we should continue our search for the ideal activation method)

Robert Spigler

Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, April 4, 2021 5:31 AM, Jorge Timón via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> So the only thing that seemed clear, using height as per bip8, it's not clear anymore.
> And, as usual, we're not talking about activation in general but about taproot activation, segwit activation...
>
> I won't make it to the meeting because I don't think I have much more to contribute that I haven't said already beyond perhaps: sigh.
> My arguments will probably ignored again, so it doesn't matter.
>
> On Sun, Apr 4, 2021, 06:39 Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> We'll be having another meeting this Tuesday, as per https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html. If you can't make it feel free to leave a comment on any agenda item below, or if you think there are other things to be discussed.
>>
>> Agenda:
>>
>> 1. AJ's update to MTP time.
>>
>> Please review https://github.com/bitcoin/bitcoin/pull/21377 as AJ updated it substantially.
>>
>> The PR is now purely MTP based, and the state machine has been simplified. This approach is intended to be compatible with a mandatory signaling period (via a LAST_CHANCE change) and makes it easier to deploy ST on signets (irrelevant for Taproot, because it is already active on all signets).
>>
>> 2. Selecting between MTP and Height
>>
>> In the previous meeting, there was no substantial publicly discussed benefit to using MTPs over height. Since agenda item 1, there is now a tangible benefit to using MTP.
>>
>> The changes AJ promulgated for MTP neutralizes the argument, mostly, that MTP was easier to review. 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.
>>
>> 3. Timeline Discussion
>> In all hope, we will reach consensus around item 2. Should that occur, we can use this time to discuss a final selection on parameters, mindful of Core's process.
>>
>> If the meeting doesn't reach rough consensus around item 2, it seems that we may fall short on the proposed schedule from last time. In this section, we can discuss realities around scheduling.
>>
>> Best,
>>
>> Jeremy
>>
>> --
>> [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 6917 bytes --]

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

[Anthony Towns]

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

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

[Jeremy]

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

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

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 4888 bytes --]

I'm pretty sure that the question of "is signalling still possible by the
time enough miners have upgraded and are ready to start signalling?"
Strongly benefits from a guaranteed number of signaling periods that height
based activation offers.  Especially for the short activation period of
Speedy Trial.

The other relevant value of giving enough time for users to upgrade is not
very sensitive.  It's not like 180 days is magic number that going over is
safe and going below is unsafe.

That said, as Jeremy has pointed out before (maybe it was on IRC), we can
almost ensure a minimum of 7 retargeting periods by carefully selecting
signaling start and end dates to line up in the middle of expected
retargeting periods that we would otherwise chose with height based
activation. Why we would rather use MTP to fake a height based activation,
I will never understand. But if this is what it takes to activate taproot,
that is fine by me.

The differences between height and MTP activation are too small to matter
that much for what is ultimately transient code.  As long as MTP activation
can pass code review it is okay with me.


On Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6096 bytes --]

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

[Adam Back]

As I understand Andrew Chow has a patchset for height based activation
of Speedy Trial, so that it would be great if people could review that
to help increase the review-cycles.

Personally I also somewhat prefer block-height based activation, and
for myself it seems like a mild step backwards to go back to MTP, when
as far as I understand most consider height-based to be a better
defined and cleaner, more predictable solution.

Adam

On Tue, 6 Apr 2021 at 15:35, Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'm pretty sure that the question of "is signalling still possible by the time enough miners have upgraded and are ready to start signalling?" Strongly benefits from a guaranteed number of signaling periods that height based activation offers.  Especially for the short activation period of Speedy Trial.
>
> The other relevant value of giving enough time for users to upgrade is not very sensitive.  It's not like 180 days is magic number that going over is safe and going below is unsafe.
>
> That said, as Jeremy has pointed out before (maybe it was on IRC), we can almost ensure a minimum of 7 retargeting periods by carefully selecting signaling start and end dates to line up in the middle of expected retargeting periods that we would otherwise chose with height based activation. Why we would rather use MTP to fake a height based activation, I will never understand. But if this is what it takes to activate taproot, that is fine by me.
>
> The differences between height and MTP activation are too small to matter that much for what is ultimately transient code.  As long as MTP activation can pass code review it is okay with me.
>
>
> On Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, <bitcoin-dev@lists.linuxfoundation.org> 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
>>
>> _______________________________________________
>> 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

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

[David A. Harding]

[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]

On Tue, Apr 06, 2021 at 10:34:57AM -0400, Russell O'Connor via bitcoin-dev wrote:
> The other relevant value of giving enough time for users to upgrade is not
> very sensitive.  It's not like 180 days is magic number that going over is
> safe and going below is unsafe.

I don't think it's the 180 days value that's important but the deadline
to upgrade before taproot activates.  With heights, some people will be
conservative and say:

  You need to upgrade by $( date -d "66 days" )

Some people will just assume 10 minutes and say:

  You need to upgrade by $( date -d "$((10 * 2016 * 13)) minutes" )

Some people might assume 9 minutes, which I think is roughly our
historic average:

  You need to upgrade by $( date -d "$((9 * 2016 * 13)) minutes" )

As a few weeks pass and the number of blocks left until activation
decreases, it's likely everyone will be saying slightly different dates.
Basically, it'll be like a few months before the recent halving where
you could go to different sites that would give you wildly different
estimates---several of them claiming to be better than the others
because they factored in ____.

We're stuck with that for halvings, but I think coordinating human
actions around heights creates unnecessary confusion.

Using Towns's updated MTP doesn't eliminate this problem, but it reduces
it significantly, especially early in the process.  Now conservative
estimators can say:

  You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )

Ten minute estimators can say:

  You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes" )

And nine minute estimators can say:

  You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 2016)) minutes" )

Those predictions are unlikely to change until shortly before the
lockin period.

I think those dates being much closer together (within 3 days) and
static for several months makes it much easier to communicate to users
(including organizations) the date by which they should upgrade if they
want to help enforce the soft fork's new rules.

As a side advantage, it also makes it easier to plan activation parties,
which is something I think we'll especially want after we finally start
doing something useful with the bikeshed we repainted so many times.  :-)

-Dave

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On Tue, Apr 6, 2021 at 12:23 PM David A. Harding <dave@dtrt.org> wrote:

>
>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )
>
> Ten minute estimators can say:
>
>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016))
> minutes" )
>
> And nine minute estimators can say:
>
>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 2016))
> minutes" )
>

It isn't  "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
"$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
minutes".

[-- Attachment #2: Type: text/html, Size: 978 bytes --]

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

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor <roconnor@blockstream.com>
wrote:

> On Tue, Apr 6, 2021 at 12:23 PM David A. Harding <dave@dtrt.org> wrote:
>
>>
>>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )
>>
>> Ten minute estimators can say:
>>
>>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016))
>> minutes" )
>>
>> And nine minute estimators can say:
>>
>>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 2016))
>> minutes" )
>>
>
> It isn't  "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
> "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
> minutes".
>

Not only that, but the "time_until_next_retargeting_period" is a variable
whose distribution could straddle between 0 days and 14 days should the
MIN_LOCKIN_TIME end up close to a retargeting boundary.  MTP risks having a
persistent two week error in estimating the activation time (which is the
time that nodes need to strive to be upgraded) which may not be resolved
until only two weeks prior to activation!  If MIN_LOCKIN_TIME ends up close
to a retargeting boundary, then the MTP estimate becomes bimodal and
provides much worse estimates than provided by height based activation,
just as we are approaching the important 4 weeks (or is it 2 weeks?) prior
to activation!

Compare this with height based activation which simply becomes more and
more accurate in its estimation consistently (until, at less than two weeks
prior to activation, the height based estimate and the corresponding MTP
estimate have identical distributions because they both become height based
at that point in time.) This works out nicely because of the overall
simpler and easier to reason about design of height based activation.

The short of it is that MTP LOCKIN only really guarantees a minimum 2 week
notice prior to activation, which is largely the purpose of that LOCKIN
period.  Whereas height based activation gives an estimate whose
distribution smoothly and continuously becomes more and more accurate as
activation approaches, with no abrupt changes in estimates.

[-- Attachment #2: Type: text/html, Size: 3015 bytes --]

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

[Anthony Towns]

On Tue, Apr 06, 2021 at 01:17:58PM -0400, Russell O'Connor via bitcoin-dev wrote:
> Not only that, but the "time_until_next_retargeting_period" is a variable whose
> distribution could straddle between 0 days and 14 days should the
> MIN_LOCKIN_TIME end up close to a retargeting boundary.

As noted in [0] the observed time frame of a single retarget period
over the last few years on mainnet is 11-17 days, so if LOCKED_IN is
determined by a min lock in time, then activation should be expected to
occur between 11 days (if the min lock in time is reached just prior to
a retarget boundary and the next period is short) and 34 days (if the
min lock in the is reached just after the retarget boundary and both
that period and the following one are long).

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018728.html 

> MTP risks having a
> persistent two week error in estimating the activation time (which is the time
> that nodes need to strive to be upgraded)

That's a range of 16 days, consistenly after the time that's specified
and which cannot be brought forward even if miners were to attempt to
a timewarp attack. 

That compares to the height based approach, which gives a similar error
for the 7 period / 3 month target, and larger errors for anything longer,
and which can be both earlier or later in attack scenarios. The errors
are worse if you consider times prior to the 2015 cut-off I used, but
hopefully that's because of the switch to ASICs and won't be repeated?

> which may not be resolved until only
> two weeks prior to activation!  If MIN_LOCKIN_TIME ends up close to a
> retargeting boundary, then the MTP estimate becomes bimodal and provides much
> worse estimates than provided by height based activation, just as we are
> approaching the important 4 weeks (or is it 2 weeks?) prior to activation!

That doesn't seem like a particularly important design goal to me? Having
a last minute two week delay seems easy to deal with, while having to
make estimates of how many blocks we might have in an X month period
X+K months in advance is not. If it were important, I expect we could
change the state machine to reflect that goal and make the limit tighter
(in non-attack scenarios).

> The short of it is that MTP LOCKIN only really guarantees a minimum 2 week
> notice prior to activation,

If the timeout is at X and MTP min lockin is at X+Y then you guarantee
a notice period of at least Y + (1 retarget period).

Cheers,
aj

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

[David A. Harding]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

(Replies to multiple emails)

On Tue, Apr 06, 2021 at 12:27:34PM -0400, Russell O'Connor wrote:
> It isn't  "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
> "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
> minutes".

Ah, drat, I forgot about that.  Thank you for correcting my oversight!

> That doesn't seem like a particularly important design goal to me? Having
> a last minute two week delay seems easy to deal with

From my perspective, that of a person focused on communicating
information that affects Bitcoin users and recommending infrastructure
adjustments that should be made to accomodate those changes, I'd find
having a predictable activation date to be of significant benefit.
Given that, an activation scheme that could provide a tight timeline
(only delayable, not accellerable, by miner shenanegeans) would be
something I'd consider an advantage of that method.

That said, it's probably not worth making the activation state machine
more complicated for when the simplicity of the machine for height-based
activations is it's chief touted benefit.

Thanks,

-Dave

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]