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>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
	connections are setup
Precedence: list


--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 &lt;jlrubin@mit.edu&gt; 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 &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org=
</a>&gt; 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--