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
|
Return-Path: <eric@voskuil.org>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 89F29C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 20:17:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 7179C87FB5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 20:17:21 +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 sYPJXhxBC8vU
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 20:17:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com
[209.85.216.49])
by hemlock.osuosl.org (Postfix) with ESMTPS id C12DD87EC0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 20:17:19 +0000 (UTC)
Received: by mail-pj1-f49.google.com with SMTP id 2so16081pjx.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 13:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=content-transfer-encoding:from:mime-version:subject:date:message-id
:references:cc:in-reply-to:to;
bh=jYcdRRb0SpZdYrjtPEtiUr0ivoKJxMMR+NBMdN5jlCM=;
b=caI+VTccrdXktixNaok+/6b+O1LMK/gBl4dO5Gy24aoXO9PcJVE/4V5vu/MbJH5xU9
MRbs5NPjwPB6wJOe9vUKquWSw/6QqQfamQUE+14TlgMEMLHGFogggxgs1QIjQfgc6TlM
yUQH6lR2DOyOx/Ixw8o3FYCmRiX3SMkeJzzfNXCPqrNU86JgG+XK+MQUqvft6GlO/Ymd
wXG8vKY+ghse28mnv8LWkLUCYOPaZamictsJ07raeURhCnQLcfG4yf3ckGzfXXODkzT8
boY9NO/7UoOFvavksX6Sd4ZpWSa50MkUOlInBRpcw7nwGJyBhb3HtvT95z2wc8hLgQWt
ka3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:content-transfer-encoding:from:mime-version
:subject:date:message-id:references:cc:in-reply-to:to;
bh=jYcdRRb0SpZdYrjtPEtiUr0ivoKJxMMR+NBMdN5jlCM=;
b=IPBzmTVquoq6ejv3boIkzQc8Q8+1BiBjboYZ0oSpVTBdHIzDhwx/VN2BxFz32bqsHU
VyVkxC7rqEw9hBDrHcv0mQAvFILcMmEfUNjexnTCyfPQdm7HR/QTQqdcXo8RcWUhKNws
MSFQBnfARzGUx8Zs0M6aOjx3AVUd0/MLHgGvGw099A0gDSXbpBfLh+VHxJuJ1aZhNlAY
PtSd+RpjTV4DqSj+MX6b41jfO5fsxcuFq083i2kFx+ZkXQgJbo/uePu7+mFV8pZ/k9FT
Ce3OoW6eb2ZPu4nwbONBtKNBxo0KeAm9CULQr7QUjMCLSQkqWSCaBvflxiI9/WUV2gFT
7Qgg==
X-Gm-Message-State: AOAM53254p/Chw8dCpSMCksHme6F+0DRrzb0YLqjqiKqcNq6yVY0/JiZ
lAGa4dfb3UTPSRao9ltaZPlTbg==
X-Google-Smtp-Source: ABdhPJwYmhjS261Q45DoDvI9FKVOwi2JICq1FFDgzXhmzhuHkzVCr7IzWXseTe1frYq0mn1wlyKKuw==
X-Received: by 2002:a17:90a:bd15:: with SMTP id
y21mr770887pjr.144.1598300239128;
Mon, 24 Aug 2020 13:17:19 -0700 (PDT)
Received: from ?IPv6:2600:380:705e:6b65:8d01:1dee:2537:4ab1?
([2600:380:705e:6b65:8d01:1dee:2537:4ab1])
by smtp.gmail.com with ESMTPSA id m7sm8219200pfm.31.2020.08.24.13.17.18
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 24 Aug 2020 13:17:18 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-C0F4CCDF-6ED9-4B16-93C9-2A2BEE501AA9
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 24 Aug 2020 13:17:17 -0700
Message-Id: <5B76307E-9810-49F1-8289-E0F0E84ACD72@voskuil.org>
References: <CAD5xwhgDWpaavk3R5gjUwMU37bRTmKC+o5hHoWVeaiW8WFQNjA@mail.gmail.com>
In-Reply-To: <CAD5xwhgDWpaavk3R5gjUwMU37bRTmKC+o5hHoWVeaiW8WFQNjA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
X-Mailer: iPhone Mail (17G80)
X-Mailman-Approved-At: Mon, 24 Aug 2020 20:21:17 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
connections are setup
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, 24 Aug 2020 20:17:21 -0000
--Apple-Mail-C0F4CCDF-6ED9-4B16-93C9-2A2BEE501AA9
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
I said security, not privacy. You are in fact exposing the feature to any no=
de that wants to negotiate for it. if you don=E2=80=99t want to expose the b=
uggy feature, then disable it. Otherwise you cannot prevent peers from acces=
sing it. Presumably peers prefer the new feature if they support it, so ther=
e is no need for this complexity.
e
> On Aug 24, 2020, at 12:59, Jeremy <jlrubin@mit.edu> wrote:
>=20
> =EF=BB=BF
>>=20
>> >> On 8/21/20 5:17 PM, Jeremy wrote:
>> >> As for an example of where you'd want multi-round, you could imagine a=
scenario where you have a feature A which gets bugfixed by the introduction=
of feature B, and you don't want to expose that you support A unless you fi=
rst negotiate B. Or if you can negotiate B you should never expose A, but fo=
r old nodes you'll still do it if B is unknown to them.
>>=20
>> This seems to imply a security benefit (I can=E2=80=99t discern any other=
rationale for this complexity). It should be clear that this is no more tha=
n trivially weak obfuscation and not worth complicating the protocol to achi=
eve.
>=20
>=20
> The benefit is not privacy oriented and I didn't intend to imply as such. T=
he benefit is that you may only wish to expose functionality to peers which s=
upport some other set of features. For example, with wtxid relay, I might wa=
nt to expose some additional functionality after establishing my peer suppor=
ts it, that peers which do not have wtxid relay should not be allowed to use=
. The benefit over just exposing all functions is then a node might be progr=
ammed to support the new feature but not wtxid relay, which can lead to some=
incompatibilities.
>=20
> You cannot implement this logic as a purely post-hoc "advertise all and th=
en figure out what is allowed" because then you require strict consistency b=
etween peers of that post-hoc feature availability implication map.
--Apple-Mail-C0F4CCDF-6ED9-4B16-93C9-2A2BEE501AA9
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">I said security, not priva=
cy. You are in fact exposing the feature to any node that wants to negotiate=
for it. if you don=E2=80=99t want to expose the buggy feature, then disable=
it. Otherwise you cannot prevent peers from accessing it. Presumably peers p=
refer the new feature if they support it, so there is no need for this compl=
exity.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div dir=3D"l=
tr"><br><blockquote type=3D"cite">On Aug 24, 2020, at 12:59, Jeremy <jlru=
bin@mit.edu> wrote:<br><br></blockquote></div><blockquote type=3D"cite"><=
div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr"><div dir=3D"auto"><div><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><b><br>
>> On 8/21/20 5:17 PM, Jeremy wrote:<br>
>> As for an example of where you'd want multi-round, you could imagin=
e a scenario where you have a feature A which gets bugfixed by the introduct=
ion of feature B, and you don't want to expose that you support A unless you=
first negotiate B. Or if you can negotiate B you should never expose A, but=
for old nodes you'll still do it if B is unknown to them.<br>
<br>
This seems to imply a security benefit (I can=E2=80=99t discern any other ra=
tionale for this complexity). It should be clear that this is no more than t=
rivially weak obfuscation and not worth complicating the protocol to achieve=
.<br></b></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">The benefit is not privacy oriented and I didn't intend to imply as such=
. The benefit is that you may only wish to expose functionality to peers whi=
ch support some other set of features. For example, with wtxid relay, I migh=
t want to expose some additional functionality after establishing my peer su=
pports it, that peers which do not have wtxid relay should not be allowed to=
use. The benefit over just exposing all functions is then a node might be p=
rogrammed to support the new feature but not wtxid relay, which can lead to s=
ome incompatibilities.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)" class=3D"gmail_default">You cannot implement this logic as a purely=
post-hoc "advertise all and then figure out what is allowed" because then y=
ou require strict consistency between peers of that post-hoc feature availab=
ility implication map.</div></div></div>
</div>
</div></blockquote></body></html>=
--Apple-Mail-C0F4CCDF-6ED9-4B16-93C9-2A2BEE501AA9--
|
