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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8D1ECC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 14:00:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 7771E87174
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 14:00:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id AHmge0Y1+80Q
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 14:00:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by hemlock.osuosl.org (Postfix) with ESMTPS id A472587038
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Feb 2021 14:00:32 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with ESMTPSA id 02B1A4AEF48;
Mon, 22 Feb 2021 14:00:29 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1614001264; t=1614002430;
bh=m3iS+SP3gIfVtXTecQyGqFqS5irqbp/R/xuYvsTiowE=;
h=From:Subject:Date:References:Cc:In-Reply-To:To:From;
b=NRDJ2y74PAUdRtJQKKJDJTGJvIQVZ2UiwJ1jNqT68nwkCFAd9BQM9uQ3iIqh6JA9B
kZ/CP9PzIOoZRCHkDcjvR3lUrafCQ09fRixt2z0xpAAuzw1BpkjHzlfnDEHhE3dTbQ
N8iCw5fNLsSyHefUJzPB4d/PeWPWFdY+KYV52mTdnu8+tJtqzWrbGCtZqWExVaHW6t
xUocrSYJBytV8y2zAMJQ7PcHAIjwVzhYGbY8M9VKmd0zaauc0X6kewSE+6dc1EgfAP
M/KEPauPiKiCey2FyqHBAXq/VeZI5fpJuS/DFAnWZ60aSy5uUDYofURHtyNgM+JWFd
UJ6Iu971VCgPw==
Content-Type: multipart/alternative;
boundary=Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 22 Feb 2021 09:00:29 -0500
Message-Id: <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>
References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au>
In-Reply-To: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au>
To: Anthony Towns <aj@erisian.com.au>
Cc: Michael Folkson <michaelfolkson@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
lockinontimeout (LOT)
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: Mon, 22 Feb 2021 14:00:33 -0000
--Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
> On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian.com.au> wrote:
>=20
> =EF=BB=BFIf a lockinontimeout=3Dtrue node is requesting compact blocks fro=
m a
> lockinontimeout=3Dfalse node during a chainsplit in the MUST_SIGNAL phase,=
> I think that could result in a ban.
>=20
>> More importantly, nodes on both sides of the fork need to find each other=
.=20
>=20
> (If there was going to be an ongoing fork there'd be bigger things to
> worry about...)
I think it should be clear that a UASF-style command line option to allow co=
nsensus rule changes in the node in the short term, immediately before a for=
k carries some risk of a fork, even if I agree it may not persist over month=
s. We can=E2=80=99t simply ignore that.
> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=3Dtrue need to be well connected so they don't=
> end up competing with each other while they're catching back up".
Between this and your above point, I think we probably agree - there is mate=
rial technical complexity hiding behind a =E2=80=9Cchange the consensus rul=
es=E2=80=9C option. Given it=E2=80=99s not a critical feature by any means, p=
utting resources into fixing these issues probably isn=E2=80=99t worth it.
Matt=
--Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><br></div><div dir=3D"ltr"=
><br><blockquote type=3D"cite">On Feb 22, 2021, at 05:16, Anthony Towns <=
aj@erisian.com.au> wrote:<br><br></blockquote></div><blockquote type=3D"c=
ite"><div dir=3D"ltr">=EF=BB=BFI<span>f a lockinontimeout=3Dtrue node is req=
uesting compact blocks from a</span><br><span>lockinontimeout=3Dfalse node d=
uring a chainsplit in the MUST_SIGNAL phase,</span><br><span>I think that co=
uld result in a ban.</span><br><span></span><br><blockquote type=3D"cite"><s=
pan>More importantly, nodes on both sides of the fork need to find each othe=
r. </span><br></blockquote><span></span><br><span>(If there was going to be a=
n ongoing fork there'd be bigger things to</span><br><span>worry about...)</=
span><br></div></blockquote><div><br></div><div>I think it should be clear t=
hat a UASF-style command line option to allow consensus rule changes in the n=
ode in the short term, immediately before a fork carries some risk of a fork=
, even if I agree it may not persist over months. We can=E2=80=99t simply ig=
nore that.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><span>I think=
the important specific case of this is something like "if a chain</span><br=
><span>where taproot is impossible to activate is temporarily the most work,=
</span><br><span>miners with lockinontimeout=3Dtrue need to be well connecte=
d so they don't</span><br><span>end up competing with each other while they'=
re catching back up".</span><br></div></blockquote><div><br></div><div>Betwe=
en this and your above point, I think we probably agree - there is material &=
nbsp;technical complexity hiding behind a =E2=80=9Cchange the consensus rule=
s=E2=80=9C option. Given it=E2=80=99s not a critical feature by any means, p=
utting resources into fixing these issues probably isn=E2=80=99t worth it.</=
div><div><br></div><div><font color=3D"#5856d6"><span style=3D"caret-color: r=
gb(88, 86, 214);">Matt</span></font></div></body></html>=
--Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63--
|
