path: root/67/bbd1aa8eedf9d0424242adbed21b5cbaf6d548

Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9BDC5C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 14:31:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 8B19B401C2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 14:31:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id dB3hY1p13GPT
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 14:31:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 88CE9401B4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 14:31:06 +0000 (UTC)
Received: from mail-il1-f176.google.com (mail-il1-f176.google.com
 [209.85.166.176]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12PEV4Qc026281
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 25 Mar 2021 10:31:05 -0400
Received: by mail-il1-f176.google.com with SMTP id 19so2307223ilj.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 07:31:04 -0700 (PDT)
X-Gm-Message-State: AOAM530RD5EdvY7lTycEs3DngvMRGMk/W7JPYaVZCyJ2TWVADik1Pbs3
 C0chCDLqX4T8za3/rsiEZATsJLQN0JDBQlKCyN0=
X-Google-Smtp-Source: ABdhPJyy0t/YsEp/5NtHRq+Nyga1smGY0vnCFJ43ZjfCfgZQynW+npfnTfz1UsV+s6oEDZnxABu5nTnVZqbSETMKv6g=
X-Received: by 2002:a05:6e02:1b0e:: with SMTP id
 i14mr6841386ilv.58.1616682664223; 
 Thu, 25 Mar 2021 07:31:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
 <20210325070204.GA10937@erisian.com.au>
In-Reply-To: <20210325070204.GA10937@erisian.com.au>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 25 Mar 2021 07:30:52 -0700
X-Gmail-Original-Message-ID: <CAD5xwhjRsNhL32cONwCTms-a8FGv+FiK3k1ihU8y5a3G1WMb9A@mail.gmail.com>
Message-ID: <CAD5xwhjRsNhL32cONwCTms-a8FGv+FiK3k1ihU8y5a3G1WMb9A@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000ea72ac05be5d4341"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
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: Thu, 25 Mar 2021 14:31:07 -0000

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

I think it's fine to move the dates back two weeks in that case; it was
unclear from the meeting transcript if people thought release would be may
1st or startheight, but via parameter flexibility we can shift everything
back 2 weeks if we want.

W.r.t. the selection of MTP there's no funny business I just estimated a
mid period MTP. I don't think midnight utc is sacred, it's 5 o'clock
somewhere.

We can adjust the parameters at your preference -- a little more or less
time shouldn't hurt, but that is also the point of picking mid period MTP
that it makes drift not matter much.

On Thu, Mar 25, 2021, 12:02 AM Anthony Towns <aj@erisian.com.au> wrote:

> On Tue, Mar 23, 2021 at 08:46:54PM -0700, Jeremy via bitcoin-dev wrote:
> > 3. Parameter Selection
> > - There is broad agreement that we should target something like a May 1st
> >   release, with 1 week from rc1 starttime/startheight,
> >   and 3 months + delta stoptime/stopheight (6 retargetting periods), and
> an
> >   activation time of around Nov 15th.
>
> I'd thought the idea was to release mid-late April, targetting a starttime
> of May 1st.
>
> > - If we select heights, it looks like the first signalling period would
> be
> >   683424, the stop height would be 695520.
>
> > - If we select times, we should target a mid-period MTP. We can shift
> this
> > closer to release, but currently it looks like a 1300 UTC May 7th start
> time and stop time would be 1300 UTC August 13th.
>
> We've traditionally done starttime/timeout at midnight UTC, seems weird
> to change. Oh, or is it a Friday-the-13th, lets have 13s everywhere
> thing?
>
> Anyway, block 695520 is about 19440 blocks away, which we'd expect to be
> 135 days, but over the past two years, 19440 blocks prior to a retarget
> boundary has been between 127 (-8) days and 137 (+2) days, and in the
> last four years, it's been between 121 (-14) days and 139 (+4) days. [0]
>
> So given block 676080 had mediantime 1616578564, I think picking a
> mediantime no later than ~139 days later, ie 1628640000 (00:00 UTC
> 11 Aug) would be the most likely to result in MTP logic matching the
> height parameters above, and a day or two earlier still might be better.
> (It will match provided MTP passes the timeout at any block in the range
> [695520, 697535])
>
> > (please check my math, if anyone is superstitious we can add a day to
> times...)
>
> It looks to me like blocks are more likely to arrive earlier than later
> (which is what we'd expect with increasing hashrate), fwiw, so adding
> days would be more likely to cause MTP to have more signalling periods
> than height-based, rather than avoid having fewer.
>
> Cheers,
> aj
>
> [0] $ for b in `seq 201600 2016 676000`; do a=$(($b-19440)); echo $((
> $(bitcoin-cli getblockheader $(bitcoin-cli getblockhash $b) | grep
> mediantime | cut -d\  -f4 | tr -d ,) -  $(bitcoin-cli getblockheader
> $(bitcoin-cli getblockhash $a) | grep mediantime | cut -d\  -f4 | tr -d ,)
> )); done
>

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

<div dir=3D"auto"><div>I think it&#39;s fine to move the dates back two wee=
ks in that case; it was unclear from the meeting transcript if people thoug=
ht release would be may 1st or startheight, but via parameter flexibility w=
e can shift everything back 2 weeks if we want.=C2=A0<div dir=3D"auto"><br>=
</div><div dir=3D"auto">W.r.t. the selection of MTP there&#39;s no funny bu=
siness I just estimated a mid period MTP. I don&#39;t think midnight utc is=
 sacred, it&#39;s 5 o&#39;clock somewhere.=C2=A0</div><div dir=3D"auto"><br=
></div>We can adjust the parameters at your preference -- a little more or =
less time shouldn&#39;t hurt, but that is also the point of picking mid per=
iod MTP that it makes drift not matter much.=C2=A0<br><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 25, 2021, 12:02=
 AM Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.a=
u</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Mar 23, 20=
21 at 08:46:54PM -0700, Jeremy via bitcoin-dev wrote:<br>
&gt; 3. Parameter Selection<br>
&gt; - There is broad agreement that we should target something like a May =
1st<br>
&gt;=C2=A0 =C2=A0release, with 1 week from rc1=C2=A0starttime/startheight,<=
br>
&gt;=C2=A0 =C2=A0and 3 months + delta stoptime/stopheight (6 retargetting p=
eriods), and an<br>
&gt;=C2=A0 =C2=A0activation time of around Nov 15th.<br>
<br>
I&#39;d thought the idea was to release mid-late April, targetting a startt=
ime<br>
of May 1st.<br>
<br>
&gt; - If we select heights, it looks like the first signalling period woul=
d be<br>
&gt;=C2=A0 =C2=A0683424, the stop height=C2=A0would be 695520.<br>
<br>
&gt; - If we select times, we should target a mid-period MTP. We can shift =
this<br>
&gt; closer to release, but currently it looks like a 1300 UTC May 7th star=
t time and stop time would be 1300 UTC August 13th.<br>
<br>
We&#39;ve traditionally done starttime/timeout at midnight UTC, seems weird=
<br>
to change. Oh, or is it a Friday-the-13th, lets have 13s everywhere<br>
thing?<br>
<br>
Anyway, block 695520 is about 19440 blocks away, which we&#39;d expect to b=
e<br>
135 days, but over the past two years, 19440 blocks prior to a retarget<br>
boundary has been between 127 (-8) days and 137 (+2) days, and in the<br>
last four years, it&#39;s been between 121 (-14) days and 139 (+4) days. [0=
]<br>
<br>
So given block 676080 had mediantime 1616578564, I think picking a<br>
mediantime no later than ~139 days later, ie 1628640000 (00:00 UTC<br>
11 Aug) would be the most likely to result in MTP logic matching the<br>
height parameters above, and a day or two earlier still might be better.<br=
>
(It will match provided MTP passes the timeout at any block in the range<br=
>
[695520, 697535])<br>
<br>
&gt; (please check my math, if anyone is superstitious we can add a day to =
times...)<br>
<br>
It looks to me like blocks are more likely to arrive earlier than later<br>
(which is what we&#39;d expect with increasing hashrate), fwiw, so adding<b=
r>
days would be more likely to cause MTP to have more signalling periods<br>
than height-based, rather than avoid having fewer.<br>
<br>
Cheers,<br>
aj<br>
<br>
[0] $ for b in `seq 201600 2016 676000`; do a=3D$(($b-19440)); echo $(( $(b=
itcoin-cli getblockheader $(bitcoin-cli getblockhash $b) | grep mediantime =
| cut -d\=C2=A0 -f4 | tr -d ,) -=C2=A0 $(bitcoin-cli getblockheader $(bitco=
in-cli getblockhash $a) | grep mediantime | cut -d\=C2=A0 -f4 | tr -d ,) ))=
; done <br>
</blockquote></div></div></div>

--000000000000ea72ac05be5d4341--