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>
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-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 &lt;jlru=
bin@mit.edu&gt; 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>
&gt;&gt; On 8/21/20 5:17 PM, Jeremy wrote:<br>
&gt;&gt; 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--