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
|
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 DA68EC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 20:33:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id C4B6488320
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 20:33:49 +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 a4gxCCt7Il4t
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 20:33:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com
[209.85.216.47])
by hemlock.osuosl.org (Postfix) with ESMTPS id A55B788301
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 20:33:48 +0000 (UTC)
Received: by mail-pj1-f47.google.com with SMTP id n3so193118pjq.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 13:33:48 -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=gCMEnYmqnUT0FE6ixSVjSyJ5w0cGUQH2u76EuEaN+4Q=;
b=pASqSd2L5G1ztFLdRcPXJbNmedi6UwL6kw2liaAf951orUf62nA1ZgRi6Ar1O5581o
Vgg8UwdTNmExbtcKMwUEgsANxxH1Xb0BIpx1UfaKBFijC6k+I29/r7qnmGmu4N9JWJzJ
Bp8GZj8bi1oc6/HU87WLsx/nY4CgG7YgLTjpb9XGIvW5e5hIa3Oh1+VYDvzwOsgvalpt
6t7e+lwfgceo0F4GX2i93VdPYMOaCRRSj89qi+PPlT3fus+/w1q4RV1UP3+KaPN780yD
q0bUxnePtrWYVdAUhUtgktkQkvwoLjRprjpuQlDpQdGwh/0w3G9CSh+86ck9u6VzKgkc
pX6w==
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=gCMEnYmqnUT0FE6ixSVjSyJ5w0cGUQH2u76EuEaN+4Q=;
b=qMZxmy0COWXRiDa9KnznMzq4LuckZsqcRhUPFrsHzsUiYjCIGrQYNcTGp7DBCYrv4H
KeJO7y264a8OTgFQNTgogBKDsdCQ3Zrx7QiY5M67j9l1J++AOFd8C35JhFqw+ClRKDS8
/h2sX6H8YJ/rPthrBUVnNcc2tWVQ0cEZFLhYTdSwKvBVBfgHmZb17qYpsinTC6Zhe7UC
ZT6Or7qkIaVCJqB3KAnJxSmiwwLvJdxDjDNG7bFHHTntIvSJYjqFDvF258avvC1xKNtl
l6X/35wowTm/IgcdOI6gzPMZj3+N7GH5TYQTyO2pJ1x+Bsa5lrZtLAE70cM1dcSH8mk1
675w==
X-Gm-Message-State: AOAM533+N9illR4R8ppZcaGCkIRRjDGqOXQSfY/VcCaieu3qSO9yFXWM
X0ymhxOi1sNkenE8eLbj/e6wgQ==
X-Google-Smtp-Source: ABdhPJyRx/JOj5tRtDap7U4gfJEfWw8xW5PsYnSG4fR9sdccFqBmlBgKKn5ZhupU0pQJa4iMT5dwKg==
X-Received: by 2002:a17:90b:784:: with SMTP id l4mr774024pjz.96.1598301228148;
Mon, 24 Aug 2020 13:33:48 -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 z15sm10656448pgz.13.2020.08.24.13.33.46
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 24 Aug 2020 13:33:47 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-643A9781-4A7F-48A5-9F56-2391D62C4996
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 24 Aug 2020 13:33:46 -0700
Message-Id: <B5077EB6-64CB-4067-96F0-5E11C074FE8C@voskuil.org>
References: <CAD5xwhiSf3isoMsVJiv5KQ3n5ymcS+StigkX_eDe5hmAGra-0Q@mail.gmail.com>
In-Reply-To: <CAD5xwhiSf3isoMsVJiv5KQ3n5ymcS+StigkX_eDe5hmAGra-0Q@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
X-Mailer: iPhone Mail (17G80)
X-Mailman-Approved-At: Mon, 24 Aug 2020 20:36:22 +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:33:50 -0000
--Apple-Mail-643A9781-4A7F-48A5-9F56-2391D62C4996
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
I see no requirement for anything here apart from exchanging a list of suppo=
rted =E2=80=9Cfeatures=E2=80=9D. Conditionally hiding a feature provides no b=
enefit. Any peer that wants it can get it (obfuscation being weak security),=
and otherwise it=E2=80=99s a non-issue.
e
> On Aug 24, 2020, at 13:22, Jeremy <jlrubin@mit.edu> wrote:
>=20
>> On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil <eric@voskuil.org> wrote:
>> I said security, not privacy. 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 th=
e buggy feature, then disable it. Otherwise you cannot prevent peers from ac=
cessing it. Presumably peers prefer the new feature if they support it, so t=
here is no need for this complexity.
>=20
> I interpreted " This seems to imply a security benefit (I can=E2=80=99t di=
scern any other rationale for this complexity). It should be clear that this=
is no more than trivially weak obfuscation and not worth complicating the p=
rotocol to achieve.", to be about obfuscation and therefore privacy.
>=20
> The functionality that I'm mentioning might not be buggy, it might just no=
t support peers who don't support another feature. You can always disconnect=
a peer who sends a message that you didn't handshake on (or maybe we should=
elbow bump given the times).
--Apple-Mail-643A9781-4A7F-48A5-9F56-2391D62C4996
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 see no requirement for a=
nything here apart from exchanging a list of supported =E2=80=9Cfeatures=E2=80=
=9D. Conditionally hiding a feature provides no benefit. Any peer that wants=
it can get it (obfuscation being weak security), and otherwise it=E2=80=99s=
a non-issue.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div d=
ir=3D"ltr"><br></div><div dir=3D"ltr"><blockquote type=3D"cite">On Aug 24, 2=
020, at 13:22, Jeremy <jlrubin@mit.edu> wrote:<br></blockquote></div><=
blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 24, 2020 at 1=
:17 PM Eric Voskuil <<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"auto"><div dir=3D"ltr">I said security, not privacy. You are in fa=
ct exposing the feature to any node that wants to negotiate for it. if you d=
on=E2=80=99t want to expose the buggy feature, then disable it. Otherwise yo=
u cannot prevent peers from accessing it. Presumably peers prefer the new fe=
ature if they support it, so there is no need for this complexity.</div></di=
v></blockquote><div><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">I interpret=
ed<b> "<span class=3D"gmail-im">
This seems to imply a security benefit (I can=E2=80=99t discern any other=20=
rationale for this complexity). It should be clear that this is no more=20
than trivially weak obfuscation and not worth complicating the protocol=20
to achieve.</span>", </b>to be about obfuscation and therefore privacy.</div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult">The functionality that I'm mentioning might not be buggy, it might just=
not support peers who don't support another feature. You can always disconn=
ect a peer who sends a message that you didn't handshake on (or maybe we sho=
uld elbow bump given the times).<br></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"=
><b></b></div></div></div>
</div></blockquote></body></html>=
--Apple-Mail-643A9781-4A7F-48A5-9F56-2391D62C4996--
|
