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
|
Return-Path: <jlrubin@mit.edu>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id A5113C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 19:59:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 9440E8547B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 19:59:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id rLhVrcGAHWxd
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 19:59:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by whitealder.osuosl.org (Postfix) with ESMTPS id 4237A81F4D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 19:59:10 +0000 (UTC)
Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com
[209.85.208.46]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07OJx7S9004784
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 24 Aug 2020 15:59:08 -0400
Received: by mail-ed1-f46.google.com with SMTP id di22so9188502edb.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 12:59:08 -0700 (PDT)
X-Gm-Message-State: AOAM532KCKqZegKMxfAS2tfSP0AgiPbq1UxDtslBopoXeP6grBR5PSVq
ThTL8yfDTr+a1nldBCEeyy5fFjJKmFOSrNfc+/I=
X-Google-Smtp-Source: ABdhPJyjS8cKZMDlhx4NOOCl29D6tnozkGRbb+NwzrEqgPi1nxkSQ/axaIYPr66MyiOScXT84HZEjdJCEQxLL5TDHA4=
X-Received: by 2002:a05:6402:1b02:: with SMTP id
by2mr4063009edb.95.1598299147748;
Mon, 24 Aug 2020 12:59:07 -0700 (PDT)
MIME-Version: 1.0
References: <afcedaf1-dd69-9402-eeeb-006bb9211b98@mattcorallo.com>
<27FE83C7-0269-4DEB-82E4-486FAFFA0DE5@voskuil.org>
In-Reply-To: <27FE83C7-0269-4DEB-82E4-486FAFFA0DE5@voskuil.org>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 24 Aug 2020 12:58:56 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgDWpaavk3R5gjUwMU37bRTmKC+o5hHoWVeaiW8WFQNjA@mail.gmail.com>
Message-ID: <CAD5xwhgDWpaavk3R5gjUwMU37bRTmKC+o5hHoWVeaiW8WFQNjA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="000000000000f24b6205ada504fa"
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 19:59:11 -0000
--000000000000f24b6205ada504fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
>
>
>
>
>
>
> * >> 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 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. 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 than trivially weak obfuscation and not worth complicatin=
g
> the protocol to achieve.*
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
which support some other set of features. For example, with wtxid relay, I
might want to expose some additional functionality after establishing my
peer supports 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 programmed to support the new feature but not wtxid relay, which
can lead to some incompatibilities.
You cannot implement this logic as a purely post-hoc "advertise all and
then figure out what is allowed" because then you require strict
consistency between peers of that post-hoc feature availability implication
map.
--000000000000f24b6205ada504fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"auto"><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;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 i=
magine a scenario where you have a feature A which gets bugfixed by the int=
roduction 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 e=
xpose 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 r=
ationale for this complexity). It should be clear that this is no more than=
trivially weak obfuscation and not worth complicating the protocol to achi=
eve.<br></b></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">The benefit is not privacy oriented and I didn't intend to im=
ply as such. The benefit is that you may only wish to expose functionality =
to peers which support some other set of features. For example, with wtxid =
relay, I might want to expose some additional functionality after establish=
ing my peer supports it, that peers which do not have wtxid relay should no=
t be allowed to use. The benefit over just exposing all functions is then a=
node might be programmed to support the new feature but not wtxid relay, w=
hich can lead to some incompatibilities.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">You cannot implement t=
his logic as a purely post-hoc "advertise all and then figure out what=
is allowed" because then you require strict consistency between peers=
of that post-hoc feature availability implication map.</div></div></div>
</div>
--000000000000f24b6205ada504fa--
|
