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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
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 67484C000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 17:18:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 55C1660B92
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 17:18:12 +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_40=-0.001, 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 pH5zVrLQhhpw
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 17:18:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com
[IPv6:2607:f8b0:4864:20::734])
by smtp3.osuosl.org (Postfix) with ESMTPS id 6837560B80
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Apr 2021 17:18:11 +0000 (UTC)
Received: by mail-qk1-x734.google.com with SMTP id x11so15688832qkp.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 06 Apr 2021 10:18:11 -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=KtcA3ZaMot2+8y1FXf+GulKqwiFo9294tW0+XrJrtVw=;
b=tz7ZcTiW7HmK3u3e70qMMdk4Na5lZnPsrlKczxkFhfc0yeaeR7k6DX06nE9XITbQt8
I9nV51pWbx4BVME7qTTjUqu7wFwdbOpXdFT1tRICsxg3jBTuNxS0x1Uvl2hpqAQLazkX
uMIyX7iDyyal1OEG486HlfdrDlUcebZp1EBGHTRRcFF9qyKvApyTnbT7ciseRpp/7gHA
HviS0Sveq+wOJa4Z+VSIJyVdnW/82dnSSzN2MYaeXYeYPYCknpiyBRKpetLlfLUj34f8
7YvS/+KoTW+N1gXyN6uCo5KqUfYZTV1VwIsuxTusDddlYtH0srq99RGoUAWaafK+TLUx
fAEw==
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=KtcA3ZaMot2+8y1FXf+GulKqwiFo9294tW0+XrJrtVw=;
b=MzQUIwlbqyF/KZoS7CHEyhu9aWLpBmQE+aYodhOJjs1WVyiX2yeFvPQ/SyyyfcgTTp
V+O3UuriXuoTAmu/6v8io88FIxT80OCY7b3ILxPO1cNUK5LVaInAvZiDyWMEP2nWCtBN
5PSAaotbtecLG2ji2B8mSbq01Qpg7V73U5NvzOTWHsFYMi294EodwCC+d+EUoBPoABd3
I8xo9MSQ5XBm4b7x2P66RAiLnM9Erc6l5ZG46lIrxmPRp4tWouVsYym3RWQgVZALODNf
lXSTQl1Hkcb/ac3bDRJd2vEZsewYO0C1RtpFAN+r4ttj8SIAu9Bh30eVjESJVz46oezt
RfOQ==
X-Gm-Message-State: AOAM532bTcnEhAccUl+E4acEkpaI2CwkiPQVqttIpn7quxWDObZo0h/c
vyu/7nS19V8Lz6FZO0VZOxtuBaiEFiN3+xakCC20kg==
X-Google-Smtp-Source: ABdhPJwJD51bzw9yi7EsjIvnBUEAfAu+IOlBOp+OBwNOelK8jLLMASCDnoR9y3fpUiQUABsVFYnoETvwyxj9fdOTIpQ=
X-Received: by 2002:a37:ad0a:: with SMTP id f10mr15065831qkm.384.1617729490145;
Tue, 06 Apr 2021 10:18:10 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAMZUoKkxMudxUsOqA3varpjiqeVv+e-QD6RB8JzEfhjSMLJqeg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 6 Apr 2021 13:17:58 -0400
Message-ID: <CAMZUoKnjjhYbYABL+iw5VivQfKTn64vV0ereOtz5VFEb6g0xvw@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000009a65e305bf50ffcd"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Anthony Towns <aj@erisian.com.au>
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 17:18:12 -0000
--0000000000009a65e305bf50ffcd
Content-Type: text/plain; charset="UTF-8"
On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor <roconnor@blockstream.com>
wrote:
> On Tue, Apr 6, 2021 at 12:23 PM David A. Harding <dave@dtrt.org> wrote:
>
>>
>> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )
>>
>> Ten minute estimators can say:
>>
>> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016))
>> minutes" )
>>
>> And nine minute estimators can say:
>>
>> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 2016))
>> minutes" )
>>
>
> It isn't "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
> "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
> minutes".
>
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. 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) 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!
Compare this with height based activation which simply becomes more and
more accurate in its estimation consistently (until, at less than two weeks
prior to activation, the height based estimate and the corresponding MTP
estimate have identical distributions because they both become height based
at that point in time.) This works out nicely because of the overall
simpler and easier to reason about design of height based activation.
The short of it is that MTP LOCKIN only really guarantees a minimum 2 week
notice prior to activation, which is largely the purpose of that LOCKIN
period. Whereas height based activation gives an estimate whose
distribution smoothly and continuously becomes more and more accurate as
activation approaches, with no abrupt changes in estimates.
--0000000000009a65e305bf50ffcd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor <<a href=3D"=
mailto:roconnor@blockstream.com">roconnor@blockstream.com</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr=
6, 2021 at 12:23 PM David A. Harding <<a href=3D"mailto:dave@dtrt.org" =
target=3D"_blank">dave@dtrt.org</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br>
=C2=A0 You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days&q=
uot; )<br>
<br>
Ten minute estimators can say:<br>
<br>
=C2=A0 You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2=
016)) minutes" )<br>
<br>
And nine minute estimators can say:<br>
<br>
=C2=A0 You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 20=
16)) minutes" )<br>
</blockquote><div><br></div><div>It isn't=C2=A0 "$MIN_LOCKIN_TIME =
+ $((10 * 2016)) minutes". It's "$MIN_LOCKIN_TIME + time unti=
l next retargeting period=C2=A0<a class=3D"gmail_plusreply" id=3D"gmail-m_5=
877218262154717088plusReplyChip-0">+</a> $((10 * 2016)) minutes".</div=
></div></div></blockquote><div><br></div>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.=C2=A0 MTP risks having a persistent two week er=
ror in estimating the activation time (which is the time that nodes need to=
strive to be upgraded) which may not be resolved until only two weeks prio=
r to activation!=C2=A0 If MIN_LOCKIN_TIME ends up close to a retargeting bo=
undary, then the MTP estimate becomes bimodal and provides much worse estim=
ates than provided by height based activation, just as we are approaching t=
he important 4 weeks (or is it 2 weeks?) prior to activation!<br></div><div=
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Compare this wi=
th height based activation which simply becomes more and more accurate in i=
ts estimation consistently (until, at less than two weeks prior to activati=
on, the height based estimate and the corresponding MTP estimate have ident=
ical distributions because they both become height based at that point in t=
ime.) This works out nicely because of the overall simpler and easier to re=
ason about design of height based activation.<br></div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">The short of it is that MTP LOC=
KIN only really guarantees a minimum 2 week notice prior to activation, whi=
ch is largely the purpose of that LOCKIN period.=C2=A0 Whereas height based=
activation gives an estimate whose distribution smoothly and continuously =
becomes more and more accurate as activation approaches, with no abrupt cha=
nges in estimates.<br></div></div>
--0000000000009a65e305bf50ffcd--
|
