path: root/a2/e7e38e4b84641b4807f39b8f3601c47f5345be

Return-Path: <roconnor@blockstream.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 07E71C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Apr 2021 14:35:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id DE33A6068B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Apr 2021 14:35:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20150623.gappssmtp.com
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 l3H83pcYJSKR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Apr 2021 14:35:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com
 [IPv6:2607:f8b0:4864:20::835])
 by smtp3.osuosl.org (Postfix) with ESMTPS id A9F33605C9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Apr 2021 14:35:12 +0000 (UTC)
Received: by mail-qt1-x835.google.com with SMTP id u8so11252539qtq.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 06 Apr 2021 07:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=57Gh/4+Zfv0ZxV0aKPCy0qqhyR4EV68HpSk8PIGxaKk=;
 b=KOjSNt4n/mN7u/fsnA6TtAkNQV2Z9qm4DNtLndaZdBFq/xUC8JMylNHR8Odz8LAt0C
 9M4XV3r6dJaiVydOXhYEBAz0/XEUxHKzZhgkfw9vAOwmbL+r6vGU+JOOax0rqmrZ4ul9
 c1S1jFttVs3ofUMpAFot/z8amWJclnq+5NrhQ8CgyTSYAeZ197m1bp/7qGanWlz/KUnn
 G6LY/UjxG1dGPGVHPrtF5R1GJSD1R5gkIy+x3q6gN8Wj+ryu4ButINiV5gzlMdKoAmCL
 tW3d9jUgWgUWD/lqPj4mNeBoe1P8g8tC/WvFolmGCDEysuAY/FrnYWKL2iM4zdo+diyG
 QcoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=57Gh/4+Zfv0ZxV0aKPCy0qqhyR4EV68HpSk8PIGxaKk=;
 b=Rx7y9VMHqeEe7Q3ijpNPPdIrwGuacwS8rGYFNV9gB8ZHg4zy3L3vUppWZhiA0m0PTB
 R/zHR92ICOnBSzB7vsmmVFeYVwA87qbAjulgtmtC0XL97gsyPi+PHBflThjxrHuGEChi
 Xn30jpjmlCU55FmwebOd4jQgN02+QUiptyflr/GBYGuEEtwH5f4gyHzG9rRSYjRbnzl/
 zdRWe5YKqcZlLk4adFVXeRkEoT20v09lzrn/siTXlZXGupMYJFsTsdbub1awpfRHoGi9
 dcgpd7aBF+8egiRVV+KqpnyG80OTwqgXzDOb5bSu47PCR3nQQGp+3m3QGdchsIoPoFKi
 56zw==
X-Gm-Message-State: AOAM533O36NRwdE8TVfkktyYDb9+SEpezCXHZayIXyTuloG3F8ZlKUMK
 xa0ADSBv93rhT540eomZQktFVnW8I5q5Nu5A+BPEzQ==
X-Google-Smtp-Source: ABdhPJyA4x1HSprEBO/89eJXzSjPY9lVrSjeR1fnA2a3LO9DKn0uwa87DZaC4k5DZftBHsaoBEDuMHzsCj/Pf7zEHFY=
X-Received: by 2002:a05:622a:110e:: with SMTP id
 e14mr27913503qty.335.1617719710696; 
 Tue, 06 Apr 2021 07:35:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgTKLhA82=PsF9EXrhvmx6zcA=ffOvHD4qt4q1sAqzhng@mail.gmail.com>
 <20210405103452.GA15866@erisian.com.au>
In-Reply-To: <20210405103452.GA15866@erisian.com.au>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 6 Apr 2021 10:34:57 -0400
Message-ID: <CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b3e26c05bf4eb802"
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2021 14:35:15 -0000

--000000000000b3e26c05bf4eb802
Content-Type: text/plain; charset="UTF-8"

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
>

--000000000000b3e26c05bf4eb802
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>I&#39;m pretty sure that the question of &quot;is si=
gnalling still possible by the time enough miners have upgraded and are rea=
dy to start signalling?&quot; Strongly benefits from a guaranteed number of=
 signaling periods that height based activation offers.=C2=A0 Especially fo=
r the short activation period of Speedy Trial.</div><div dir=3D"auto"><div =
dir=3D"auto"><br></div><div dir=3D"auto">The other relevant value of giving=
 enough time for users to upgrade is not very sensitive.=C2=A0 It&#39;s not=
 like 180 days is magic number that going over is safe and going below is u=
nsafe.</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">That said, =
as Jeremy has pointed out before (maybe it was on IRC), we can almost ensur=
e a minimum of 7 retargeting periods by carefully selecting signaling start=
 and end dates to line up in the middle of expected retargeting periods tha=
t we would otherwise chose with height based activation. Why we would rathe=
r use MTP to fake a height based activation, I will never understand. But i=
f this is what it takes to activate taproot, that is fine by me.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">The differences between height and=
 MTP activation are too small to matter that much for what is ultimately tr=
ansient code.=C2=A0 As long as MTP activation can pass code review it is ok=
ay with me.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br><div cla=
ss=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Mo=
n., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Apr 03, =
2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:<br>
&gt; As such, the main conversation in this agenda item is<br>
&gt; around the pros/cons of height or MTP and determining if we can reach =
consensus<br>
&gt; on either approach.<br>
<br>
Here&#39;s some numbers.<br>
<br>
Given a desired signalling period of xxx days, where signaling begins<br>
on the first retarget boundary after the starttime and ends on the last<br>
retarget boundary before the endtime, this is how many retarget periods<br>
you get (based on blocks since 2015-01-01):<br>
<br>
=C2=A090 days: mainnet=C2=A0 5-7 full 2016-block retarget periods<br>
180 days: mainnet 11-14<br>
365 days: mainnet 25-27<br>
730 days: mainnet 51-55<br>
<br>
(This applies to non-signalling periods like the activation/lock in delay<b=
r>
too of course. If you change it so that it ends at the first retarget<br>
period after endtime, all the values just get incremented -- ie, 6-8,<br>
12-15 etc)<br>
<br>
If I&#39;ve got the maths right, then requiring 1814 of 2016 blocks to sign=
al,<br>
means that having 7 periods instead of 5 lets you get a 50% chance of<br>
successful activation by maintaining 89.04% of hashpower over the entire<br=
>
period instead of 89.17%, while 55 periods instead of 51 gives you a 50%<br=
>
chance of success with 88.38% hashpower instead of 88.40% hashpower.<br>
So the &quot;repeated trials&quot; part doesn&#39;t look like it has any si=
gnificant<br>
effect on mainnet.<br>
<br>
If you target yy periods instead of xxx days, starting and ending on a<br>
retarget boundary, you get the following stats from the last few years<br>
of mainnet (again starting at 2015-01-01):<br>
<br>
=C2=A01 period:=C2=A0 mainnet 11-17 days (range 5.2 days)<br>
=C2=A07 periods: mainnet 87-103 days (range 15.4 days)<br>
13 periods: mainnet 166-185 days (range 17.9 days)<br>
27 periods: mainnet 352-377 days (range 24.4 days)<br>
54 periods: mainnet 711-747 days (range 35.0 days)<br>
<br>
As far as I can see the questions that matter are:<br>
<br>
=C2=A0* is signalling still possible by the time enough miners have upgrade=
d<br>
=C2=A0 =C2=A0and are ready to start signalling?<br>
<br>
=C2=A0* have nodes upgraded to enforce the new rules by the time activation=
<br>
=C2=A0 =C2=A0occurs, if it occurs?<br>
<br>
But both those benefit from less real time variance, rather than less<br>
variance in the numbers of signalling periods, at least in every way<br>
that I can think of.<br>
<br>
Corresponding numbers for testnet:<br>
<br>
=C2=A090 days: testnet=C2=A0 =C2=A05-85<br>
180 days: testnet=C2=A0 23-131<br>
365 days: testnet=C2=A0 70-224<br>
730 days: testnet 176-390<br>
<br>
(A 50% chance of activating within 5 periods requires sustaining 89.18%<br>
hashpower; within 85 periods, 88.26% hashpower; far smaller differences<br>
with all the other ranges -- of course, presumably the only way the<br>
higher block rates ever actually happen is by someone pointing an ASIC at<b=
r>
testnet, and thus controlling 100% of blocks for multiple periods anyway)<b=
r>
<br>
=C2=A0 1 period:=C2=A0 testnet 5.6minutes-26 days (range 26.5 days)<br>
=C2=A013 periods: testnet 1-135 days (range 133.5 days)<br>
=C2=A027 periods: testnet 13-192 days (range 178.3 days)<br>
=C2=A054 periods: testnet 39-283 days (range 243.1 days)<br>
100 periods: testnet 114-476 days (range 360.9 days)<br>
=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&#39;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 worth of signalling is ava=
ilable)<br>
132 periods: testnet 184-583 days (range 398.1 days)<br>
225 periods: testnet 365-877 days (range 510.7 days)<br>
390 periods: testnet 725-1403 days (range 677.1 days)<br>
<br>
[0] <a href=3D"https://github.com/bitcoin/bips/pull/1081#pullrequestreview-=
621934640" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.c=
om/bitcoin/bips/pull/1081#pullrequestreview-621934640</a><br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--000000000000b3e26c05bf4eb802--