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
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
|
Return-Path: <g.andrew.stone@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5BF2FC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 13:59:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 49D8D86969
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 13:59:40 +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 ZED8z3+gVgod
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 13:59:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com
[209.85.216.41])
by whitealder.osuosl.org (Postfix) with ESMTPS id DC835866CA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 13:59:38 +0000 (UTC)
Received: by mail-pj1-f41.google.com with SMTP id mw10so4268901pjb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2020 06:59:38 -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=eq+UPc9tlJXcHBgzPTUsrazNFFfW7Jdo2wrMTFY10k8=;
b=g7v4AtyLcGQh7anmBjnOfLBi+4MFmO6x4YMBoYXrgjQufUP4PfNTLtaifk5kffseOP
gE/IgTBCwurlh1pAznSqtiQPJOKnpp0NcOkedsLLBQkmGz4J8d/T2y8GGerkHEc5Lo0i
QjmpQE46f4tEwTsiJAfNtMlzWbDIzDygS0pRKhPWBzhx2wpbGDsvYqgiBilR3KhX+sFH
LJmAFSA+2McPg1N5cVlgkWmVzZwoVCeitOb40klxnU2Owudv50wduNioCRDdPudOuACz
3JSkJt5SfDhwdNmGSBS7SCPnIvyUx2qIAvmJN3AU03xNZ9Rkzz4EOkRwSrwX/K/w1R8e
GT6Q==
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=eq+UPc9tlJXcHBgzPTUsrazNFFfW7Jdo2wrMTFY10k8=;
b=AXLoD2T88ktt+qrC0gWgNlyoujSkbf3QO9AHXpTuo2d+J3r3XQ+a0q80mXNfha8geX
WQWvF4yX6BLOQZIdNQY2XAgSAce/OGASVeM+yAtmcX2YA3gFgSYOjXlicgpf4IchVTY7
9SSux8Eip1qWhXjOCk+yKjABMdpuy2fJADipunEbo288gvWI7bpaU+aEbAT8+ttISxWr
Nv2XtyjN5OtNqRpnISfqM5YkcV2MGeOXPUAc4RigSH2jFORgjGWpm800Ms/QHegC2Ti+
oj4fXYQsnHfP9A5NquyK/Tw0AzMKT3364KUc2VOGHj7Mno7WLqXyBckOVMwAg3ra693t
NM8g==
X-Gm-Message-State: AOAM533vAgiKV+yQG8jhp+JrVEQOZ9glRSXH46Wo2G2N7hS90+K5jGEV
e2EH5sriuz2Q0UvvRxVsOBYeSOWwYw7AoPAQjYI=
X-Google-Smtp-Source: ABdhPJyhQBGh/ycegeMfYjsKSJaKaMjJxeCsgL3A7hSYogeQbNyaHLl/BhTgeGXsVU8A9iBYblTMUrAJbyroR8AUT+s=
X-Received: by 2002:a17:90a:4214:: with SMTP id
o20mr4712371pjg.232.1598277578379;
Mon, 24 Aug 2020 06:59:38 -0700 (PDT)
MIME-Version: 1.0
References: <afcedaf1-dd69-9402-eeeb-006bb9211b98@mattcorallo.com>
<27FE83C7-0269-4DEB-82E4-486FAFFA0DE5@voskuil.org>
<CAFp6fsFUuFLjtUWhR3k-0P79r9-QRpuEZrcQfb96jEYdV0RD4Q@mail.gmail.com>
In-Reply-To: <CAFp6fsFUuFLjtUWhR3k-0P79r9-QRpuEZrcQfb96jEYdV0RD4Q@mail.gmail.com>
From: "G. Andrew Stone" <g.andrew.stone@gmail.com>
Date: Mon, 24 Aug 2020 09:59:26 -0400
Message-ID: <CAHUwRvvAG08LauksreAfbPLmZp__Ab6Ja7VH_oS_foK+SVso=w@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004fd46805ad9fff06"
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 13:59:40 -0000
--0000000000004fd46805ad9fff06
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Since discussion around allowing unknown messages or not allowing them
seems contentious, I'd like to offer up another possibility: create a
single new message, XVERSION, (and bump the protocol rev) which is a
key-value array of arbitrary data. Any protocol extension can then choose
a new key (with a 32 or 64 bit keyspace you can basically hand out prefixes
to any implementation that wants one) and publish custom data via this
message without needing to bump the protocol rev field. Typical "custom
data" would be the min and max supported version of some specific extended
protocol, but any data is possible since the "value" field can be
serialized via the same network serialization format. It therefore doubles
as a "configuration" message as well as protocol extension negotiation.
For example, we use it to communicate the maximum unconfirmed chain a node
will commit to the mempool, and peers don't bother to send transactions
that exceed this limit.
You can find a specification here:
https://gitlab.com/bitcoinunlimited/BCHUnlimited/-/blob/dev/doc/xversionmes=
sage.md
Code has been deployed for a long time.
Regards,
Andrew
On Mon, Aug 24, 2020 at 5:44 AM Suhas Daftuar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 i=
nto 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 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.
>>
>> This seems to imply a security benefit (I can=E2=80=99t discern any othe=
r
>> rationale for this complexity). It should be clear that this is no more
>> than trivially weak obfuscation and not worth complicating the protocol =
to
>> achieve.
>>
>> >> An example of this would be (were it not already out without a featur=
e
>> negotiation existing) WTXID/TXID relay.
>> >> The SYNC primitve simply codifies what order messages should be in an=
d
>> when you're done for a phase of negotiation offering something. It can b=
e
>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000004fd46805ad9fff06
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Since discussion around allowing unknown messages or =
not allowing them seems contentious, I'd like to offer up another possi=
bility: create a single new message, XVERSION, (and bump the protocol rev) =
which is a key-value array of arbitrary data.=C2=A0 Any protocol extension =
can then choose a new key (with a 32 or 64 bit keyspace you can basically h=
and out prefixes to any implementation that wants one)=C2=A0 and publish cu=
stom data via this message without needing to bump the protocol rev field.=
=C2=A0 Typical "custom data" would be the min and max supported v=
ersion of some specific extended protocol, but any data is possible since t=
he "value" field can be serialized via the same network serializa=
tion format.=C2=A0 It therefore doubles as a "configuration" mess=
age as well as protocol extension negotiation.=C2=A0 For example, we use it=
to communicate the maximum unconfirmed chain a node will commit to the mem=
pool, and peers don't bother to send transactions that exceed this limi=
t.</div><div><br></div><div>You can find a specification here:<br></div><di=
v><a href=3D"https://gitlab.com/bitcoinunlimited/BCHUnlimited/-/blob/dev/do=
c/xversionmessage.md">https://gitlab.com/bitcoinunlimited/BCHUnlimited/-/bl=
ob/dev/doc/xversionmessage.md</a></div><div><br></div><div>Code has been de=
ployed for a long time.</div><div><br></div><div>Regards,</div><div>Andrew<=
br></div><div><br> </div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Mon, Aug 24, 2020 at 5:44 AM Suhas Daftuar via =
bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi all,<div><br></div><=
div>Thanks for the helpful discussion.=C2=A0</div><div><br></div><div>My pr=
imary motivation in starting this thread was to establish what the expectat=
ions are for new feature deployment (particularly whether the protocol vers=
ion 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 wa=
y that I think meaningfully hinders future work.=C2=A0 So I'm happy to =
leave it at that and withdraw my suggestion.</div><div><br></div><div>Cheer=
s,</div><div>Suhas</div><div><br></div><div></div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 23, 2020 at 1=
:51 PM Eric Voskuil via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,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>
_______________________________________________<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>
--0000000000004fd46805ad9fff06--
|
