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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8EAFDC000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 19:48:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 8A4096067D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 19:48:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.202
X-Spam-Level: *
X-Spam-Status: No, score=1.202 tagged_above=-999 required=5
tests=[BAYES_50=0.8, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001,
SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001]
autolearn=no autolearn_force=no
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 1AI8NhgOWud6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 19:48:29 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 7BB066067B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 19:48:29 +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 1lTrgU-0006M8-CI; Wed, 07 Apr 2021 05:48:26 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 07 Apr 2021 05:48:19 +1000
Date: Wed, 7 Apr 2021 05:48:19 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210406194819.GA29761@erisian.com.au>
References: <CAD5xwhgTKLhA82=PsF9EXrhvmx6zcA=ffOvHD4qt4q1sAqzhng@mail.gmail.com>
<20210405103452.GA15866@erisian.com.au>
<CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
<20210406162216.k34aplxwznh5z25v@ganymede>
<CAMZUoKkxMudxUsOqA3varpjiqeVv+e-QD6RB8JzEfhjSMLJqeg@mail.gmail.com>
<CAMZUoKnjjhYbYABL+iw5VivQfKTn64vV0ereOtz5VFEb6g0xvw@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: <CAMZUoKnjjhYbYABL+iw5VivQfKTn64vV0ereOtz5VFEb6g0xvw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
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 19:48:30 -0000
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
|
