1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id D74EFC000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Mar 2021 07:02:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id B927F4013A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Mar 2021 07:02:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, UNPARSEABLE_RELAY=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 27wn3QBR-C6V
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Mar 2021 07:02:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp2.osuosl.org (Postfix) with ESMTPS id DE6BB400CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Mar 2021 07:02:15 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1lPK0P-00011S-KT; Thu, 25 Mar 2021 17:02:11 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 25 Mar 2021 17:02:04 +1000
Date: Thu, 25 Mar 2021 17:02:04 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210325070204.GA10937@erisian.com.au>
References: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
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 07:02:16 -0000
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
|
