MIME-Version: 1.0
References: <CAD5xwhgTKLhA82=PsF9EXrhvmx6zcA=ffOvHD4qt4q1sAqzhng@mail.gmail.com>
 <20210405103452.GA15866@erisian.com.au>
 <CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
In-Reply-To: <CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
Date: Tue, 6 Apr 2021 14:51:21 +0000
Message-ID: <CALqxMTE5ovk8dCQAGqqdGL3dnW2kWwQ+2hjAExe5SqVc7BtTHA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th
 19:00 UTC bitcoin/bitcoin-dev
Precedence: list

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?" Stron=
gly benefits from a guaranteed number of signaling periods that height base=
d activation offers.  Especially for the short activation period of Speedy =
Trial.
>
> The other relevant value of giving enough time for users to upgrade is no=
t very sensitive.  It's not like 180 days is magic number that going over i=
s 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 si=
gnaling start and end dates to line up in the middle of expected retargetin=
g periods that we would otherwise chose with height based activation. Why w=
e would rather use MTP to fake a height based activation, I will never unde=
rstand. But if this is what it takes to activate taproot, that is fine by m=
e.
>
> The differences between height and MTP activation are too small to matter=
 that much for what is ultimately transient code.  As long as MTP activatio=
n 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 dela=
y
>> 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 signa=
l,
>> 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 a=
t
>> 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-62193464=
0
>>
>> 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