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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
Return-Path: <sdaftuar@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 17E0CC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 09:44:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 00AE686DBD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 09:44:21 +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 UixTxPmQFuZ6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 09:44:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-il1-f173.google.com (mail-il1-f173.google.com
[209.85.166.173])
by whitealder.osuosl.org (Postfix) with ESMTPS id E681C86BC4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 09:44:19 +0000 (UTC)
Received: by mail-il1-f173.google.com with SMTP id 77so6662993ilc.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 02:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=8MR6NUcVN3lkLTwCc6cUlLoBNyKL8lTVn0sho4kQgw8=;
b=Kp54LCIWI99jAGFki1W++JAEFhnBeciO49S8s3GhP3JB7tpvRMpszJW73gPeAUyFv6
b7TM7ZPFtGAeoJSfh8S+JIk4irHkNHsiUf4Xf4FweW61UJdBqfcmdIm09bql9YCCkf9x
txwD2F8mgRsRphq5pQsbyMomRvQlFW+atElaXVkS55MPVsGlJtCM2EY7u3oEG2BXhcce
fWlCDUPQX15mFC5y/eeWvoyUreKq/fjEZLQSCxzuTPpuSQMgL+jbd4jerhaGGtF6PGWx
fzsOjFTw+bO8ZAmztJ5Wwo5nnrvi5u7vAU2qiVP2vfuGJCEVilmvQMa4soP0hn1pNDFg
+MXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=8MR6NUcVN3lkLTwCc6cUlLoBNyKL8lTVn0sho4kQgw8=;
b=sTgkTkq4i3NW5GYQJMWLyM6t6IMtspqocGtMNy5QN10kUD//VAmtWVJqAM9dzCjW2S
YpjY4zOhaPfcqIfQobwtstJMdHEGR5yvVFUIujxuWVO0PNoDEV5TQomE9Xjm60bfg6tA
/f+BSppWjmsVqHstBqV+S6jik5jJsHdcUj7lxwPAGWAp00s2k1VHZHXgNZvcuz8oqY1L
fypySFD59KhgkriJpXUH9R6VYOyBCvD9RfJRzD4yX5vCa6tQh9Ig8T3kWpzYWaiBvCZJ
JNsNbPEhOq3yyzd+hzPnsrDS586uPsJNiv4+UVElJUtQiyCVIrSkjA6hrMDPiChIXXQg
yfDQ==
X-Gm-Message-State: AOAM532j4TfpOlRc4RAbIg/IQlt97sbiEqn9zJForyaU+roiIwrk2rNy
LlejPuxLgvoPJa8Zad0BGvLzMV5yHml3Z4eJoGMjq7U5JYaSNw==
X-Google-Smtp-Source: ABdhPJyslvM9nIqRjePdstLy3CsTrL9lsGSVaCerUiU7cS7Qfh6tpjMBEG/gzESZYd79x3aca2FOPI7HtCElbZYAIrM=
X-Received: by 2002:a05:6e02:673:: with SMTP id
l19mr4109978ilt.121.1598262258949;
Mon, 24 Aug 2020 02:44:18 -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: Suhas Daftuar <sdaftuar@gmail.com>
Date: Mon, 24 Aug 2020 05:44:07 -0400
Message-ID: <CAFp6fsFUuFLjtUWhR3k-0P79r9-QRpuEZrcQfb96jEYdV0RD4Q@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000033e3f505ad9c6e9e"
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 09:44:21 -0000
--00000000000033e3f505ad9c6e9e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi all,
Thanks for the helpful discussion.
My primary motivation in starting this thread was to establish what the
expectations are for new feature deployment (particularly whether the
protocol version should continue to be bumped or not), and I think I have
that answer -- different from what I proposed when I started this thread,
but not in a way that I think meaningfully hinders future work. So I'm
happy to leave it at that and withdraw my suggestion.
Cheers,
Suhas
On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Aug 21, 2020, at 15:16, Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
> >
> > =EF=BB=BFHmm, could that not be accomplished by simply building this in=
to new
> messages? eg, send "betterprotocol", if you see a verack and no
> "betterprotocol" from your peer, send "worseprotocol" before you send a
> "verack".
> >
> > Matt
> >
> >> 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 introducti=
on
> 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, b=
ut
> 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 complicating the protocol t=
o
> achieve.
>
> >> An example of this would be (were it not already out without a feature
> negotiation existing) WTXID/TXID relay.
> >> The SYNC primitve simply codifies what order messages should be in and
> when you're done for a phase of negotiation offering something. It can be
> done without, but then you have to be more careful to broadcast in the
> correct order and it's not clear when/if you should wait for more time
> before responding.
> >> On Fri, Aug 21, 2020 at 2:08 PM Jeremy <jlrubin@mit.edu <mailto:
> jlrubin@mit.edu>> wrote:
> >> Actually we already have service bits (which are sadly limited)
> which allow negotiation of non bilateral feature
> >> support, so this would supercede that.
> >> --
> >> @JeremyRubin <https://twitter.com/JeremyRubin><
> https://twitter.com/JeremyRubin>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000033e3f505ad9c6e9e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi all,<div><br></div><div>Thanks for the helpful discussi=
on.=C2=A0</div><div><br></div><div>My primary motivation in starting this t=
hread was to establish what the expectations are for new feature deployment=
(particularly whether the protocol version should continue to be bumped or=
not), and I think I have that answer -- different from what I proposed whe=
n I started this thread, but not in a way that I think meaningfully hinders=
future work.=C2=A0 So I'm happy to leave it at that and withdraw my su=
ggestion.</div><div><br></div><div>Cheers,</div><div>Suhas</div><div><br></=
div><div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-de=
v <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><br>
> On Aug 21, 2020, at 15:16, Matt Corallo <<a href=3D"mailto:lf-lists=
@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.com</a>> wrote:=
<br>
> <br>
> =EF=BB=BFHmm, could that not be accomplished by simply building this i=
nto new messages? eg, send "betterprotocol", if you see a verack =
and no "betterprotocol" from your peer, send "worseprotocol&=
quot; before you send a "verack".<br>
> <br>
> Matt<br>
> <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>
<br>
>> An example of this would be (were it not already out without a fea=
ture negotiation existing) WTXID/TXID relay.<br>
>> The SYNC primitve simply codifies what order messages should be in=
and when you're done for a phase of negotiation offering something. It=
can be done without, but then you have to be more careful to broadcast in =
the correct order and it's not clear when/if you should wait for more t=
ime before responding.<br>
>> On Fri, Aug 21, 2020 at 2:08 PM Jeremy <<a href=3D"mailto:jlrub=
in@mit.edu" target=3D"_blank">jlrubin@mit.edu</a> <mailto:<a href=3D"mai=
lto:jlrubin@mit.edu" target=3D"_blank">jlrubin@mit.edu</a>>> wrote:<b=
r>
>>=C2=A0 =C2=A0 Actually we already have service bits (which are sadl=
y limited) which allow negotiation of non bilateral feature<br>
>>=C2=A0 =C2=A0 support, so this would supercede that.<br>
>>=C2=A0 =C2=A0 --<br>
>>=C2=A0 =C2=A0 @JeremyRubin <<a href=3D"https://twitter.com/Jerem=
yRubin" rel=3D"noreferrer" target=3D"_blank">https://twitter.com/JeremyRubi=
n</a>><<a href=3D"https://twitter.com/JeremyRubin" rel=3D"noreferrer"=
target=3D"_blank">https://twitter.com/JeremyRubin</a>><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000033e3f505ad9c6e9e--
|
