summaryrefslogtreecommitdiff
path: root/c3/ab56d3586b358b17963b74301812ce8bd710da
blob: 8d869f59bc319e26ccfb270b86e987fab6149c00 (plain)
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
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
Return-Path: <eric@voskuil.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 08777C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Aug 2020 21:51:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id BD35F2035C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Aug 2020 21:51:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 1GFKIYmVxNqY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Aug 2020 21:51:21 +0000 (UTC)
X-Greylist: delayed 00:23:37 by SQLgrey-1.7.6
Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com
 [209.85.167.195])
 by silver.osuosl.org (Postfix) with ESMTPS id 04B5F20450
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Aug 2020 21:51:20 +0000 (UTC)
Received: by mail-oi1-f195.google.com with SMTP id j7so16140871oij.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Aug 2020 14:51:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=F5YBEVlobZzZ6l9qMRq1mzwd98RmqT7VPrHutsyhf5U=;
 b=iWxPh4DA1jP9EWH2b5Asl2EiDML1tk3LGgBJVwPkPpUqyoze3P5xBTu1gi7ZbculWe
 i4StOgolAFgU0I1vrZ47mJHkR4vYnlSLfU58MFxntnSz7mba28aZiVh80HF9vn9afUFA
 qWzBYoDk66QOIfhkcAFf05ug51f0VQME493jPVy4TEE0BEh2mWnQzaNJ70zuajE7jooL
 J4ho9lsJZvBTLpjiruw10w74Dyw1KAuDrUWk71DAa0bRu3e+ZgT6SUaWqw6dLs/1eZbC
 DO1vf1/CRYxpG3oQiyHRArLEkUeujLNk1+uN4rlG+PDFgHqVjYO12S3GhnlIFVEFB68n
 7AeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=F5YBEVlobZzZ6l9qMRq1mzwd98RmqT7VPrHutsyhf5U=;
 b=Cc6+k8aw9TPO/pAsGLaiJD80cjzHAMYNzN/uQsOfRN4DTNQvl3PlBnCXx+sBiCKEbv
 6saJOmXg3S0YrbTe8G187hW8yU256NX9eb57hfxICt8v1Wr/DcWrox6Gt2I+OeNYMYUk
 pFdUc4JLFfKer0zIlLUHsaNCpLnQ3uW8M7K/cQCvM77Tu54iUNvFjBm12z0a/8QR1MSd
 gOGq0dMfgMBlt3gSKRkZNcm4wFC0fH0576trxKaP1BOIv531ciRGzQNC4a9+tgtHhE9z
 v/qnWqmNwnw6wBKVJKWB5xRj5YvMJcPa0Lia4PAJr4UY2DYLJkcfjnEPTn9ArP0qcY71
 7GcQ==
X-Gm-Message-State: AOAM532tr4vsIpWGKo8BBgY/IDGQRFI2KQXU6uAA9xlOAQ1KQRnAbUne
 R4NfTBWNkTG4ZEXBdzdZIvckqKOeRTdBTw==
X-Google-Smtp-Source: ABdhPJyQuDp36nUf/1q+MpGqFqe3lVdSXwH5wD9QD1fjgdRzBWTVTlZ+e7yR79imwiQ7uRDB8TGxoA==
X-Received: by 2002:a17:90a:5298:: with SMTP id
 w24mr13343912pjh.221.1597699316124; 
 Mon, 17 Aug 2020 14:21:56 -0700 (PDT)
Received: from ?IPv6:2600:380:7066:ce6e:c976:12fb:75f1:c075?
 ([2600:380:7066:ce6e:c976:12fb:75f1:c075])
 by smtp.gmail.com with ESMTPSA id x14sm21340292pfj.157.2020.08.17.14.21.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2020 14:21:55 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-5EE96465-E05B-480D-B8C1-43DC55EBB4B7
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 17 Aug 2020 14:21:53 -0700
Message-Id: <6FCCEC96-02F7-48D7-92EC-52234B94805B@voskuil.org>
References: <CAFp6fsH==PJ38vGvCGUr3AVS8XmQEjvLkNaopAhu0vY7xQjgAw@mail.gmail.com>
In-Reply-To: <CAFp6fsH==PJ38vGvCGUr3AVS8XmQEjvLkNaopAhu0vY7xQjgAw@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>
X-Mailer: iPhone Mail (17G68)
X-Mailman-Approved-At: Mon, 17 Aug 2020 21:53:52 +0000
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, 17 Aug 2020 21:51:26 -0000


--Apple-Mail-5EE96465-E05B-480D-B8C1-43DC55EBB4B7
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Suhas,

It seems to me that your first two paragraphs contradict each other, so I=E2=
=80=99m not sure we have understanding. As you say in the first paragraph, a=
 peer would never get messages that it does not understand, so there is no c=
hance that missing a protocol change would matter.

In case it=E2=80=99s not understood, version negotiation provides each peer w=
ith the maximum supported protocol version of the other. Once complete both h=
ave negotiated to the highest common version. No message not supported at th=
at version may be sent by either.

If the protocol was to accept *any* message traffic then it will cease to be=
 a protocol. People will drop in their changes without obtaining broad suppo=
rt, and peers will evolve to the point of no longer being peers. They won=E2=
=80=99t speak the same language and the =E2=80=9Cnetwork=E2=80=9D will be li=
ttle more than a broadcast transport, broadcasting all traffic to all peers,=
 whether it=E2=80=99s for them or not.

People need to either build support or build a distinct network. That=E2=80=99=
s the actual coordination issue, which is inherent to protocol development.

Best,
e

> On Aug 17, 2020, at 13:40, Suhas Daftuar <sdaftuar@gmail.com> wrote:
>=20
> Hi Eric,
>=20
> Thanks for your response.  If I understand correctly, you're suggesting th=
at in the future we do the same as what was done in BIP 339, of accompanying=
 new messages (which are optional) with a protocol version bump, so that net=
work clients are never reading unknown messages from a peer (and can be free=
 to disconnect a peer for sending an unknown message)?
>=20
> I think that works fine, so if indeed there will be software that will exp=
ect things to operate this way then I can withdraw the suggestion I've made i=
n this thread.  However I wanted to clarify that this is what you suggest, b=
ecause there is another downside to this approach (beyond the sequential nat=
ure of sequence numbers that you mention) -- if a software implementation mi=
sses a proposed new protocol upgrade, and thus fails to parse (and ignore) s=
ome proposed new message, the result can be a network split down the road as=
 incompatible clients get slowly upgraded over time.=20
>=20
> I think this coordination cost is something to be concerned about -- for i=
nstance, the lack of response to my wtxid-relay proposal made me wonder if o=
ther software would be implementing something to account for the new message=
 that proposal introduces (for clients with version >=3D 70016).  It's reaso=
nable for people to be busy and miss things like this, and I think it's wort=
h considering whether there's a safer way for us to deploy changes.
>=20
> That said, I don't think this coordination cost is unbearable, so as long a=
s we have a process for making p2p protocol improvements I'm not too worried=
 about what mechanism we use.  So if this concern over coordination of chang=
es doesn't sway you, I think we can continue to just bump protocol version a=
t the same time as deploying new messages, as we have been doing, and hope t=
hat we don't run into problems down the road. =20
>=20
> If I have misunderstood how you think we should be making future protocol c=
hanges, please let me know.
>=20
> Thanks,
> Suhas
>=20
>=20
>=20
>> On Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil <eric@voskuil.org> wrote:
>> A requirement to ignore unknown (invalid) messages is not only a protocol=
 breaking change but poor protocol design. The purpose of version negotiatio=
n is to determine the set of valid messages. Changes to version negotiation i=
tself are very problematic.
>>=20
>> The only limitation presented by versioning is that the system is sequent=
ial. As such, clients that do not wish to implement (or operators who do not=
 wish to enable) them are faced with a problem when wanting to support later=
 features. This is resolvable by making such features optional at the new pr=
otocol level. This allows each client to limit its communication to the nego=
tiated protocol, and allows ignoring of known but unsupported/disabled featu=
res.
>>=20
>> Sorry I missed your earlier post. Been distracted for a while.
>>=20
>> e
>>=20
>>=20
>>>> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>>>>=20
>>> =EF=BB=BF
>>> Hi,
>>>=20
>>> Back in February I posted a proposal for WTXID-based transaction relay[1=
] (now known as BIP 339), which included a proposal for feature negotiation t=
o take place prior to the VERACK message being received by each side.  In my=
 email to this list, I had asked for feedback as to whether that proposal wa=
s problematic, and didn't receive any responses.
>>>=20
>>> Since then, the implementation of BIP 339 has been merged into Bitcoin C=
ore, though it has not yet been released.
>>>=20
>>> In thinking about the mechanism used there, I thought it would be helpfu=
l to codify in a BIP the idea that Bitcoin network clients should ignore unk=
nown messages received before a VERACK.  A draft of my proposal is available=
 here[2].
>>>=20
>>> I presume that software upgrading past protocol version 70016 was alread=
y planning to either implement BIP 339, or ignore the wtxidrelay message pro=
posed in BIP 339 (if not, then this would create network split concerns in t=
he future -- so I hope that someone would speak up if this were a problem). =
 When we propose future protocol upgrades that would benefit from feature ne=
gotiation at the time of connection, I think it would be nice to be able to u=
se the same method as proposed in BIP 339, without even needing to bump the p=
rotocol version.  So having an understanding that this is the standard of ho=
w other network clients operate would be helpful.
>>>=20
>>> If, on the other hand, this is problematic for some reason, I look forwa=
rd to hearing that as well, so that we can be careful about how we deploy fu=
ture p2p changes to avoid disruption.
>>>=20
>>> Thanks,
>>> Suhas Daftuar
>>>=20
>>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Februar=
y/017648.html
>>>=20
>>> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-ne=
gotiation/bip-p2p-feature-negotiation.mediawiki
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-5EE96465-E05B-480D-B8C1-43DC55EBB4B7
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">Hi Suhas,</div><div dir=3D=
"ltr"><br></div><div dir=3D"ltr">It seems to me that your first two paragrap=
hs contradict each other, so I=E2=80=99m not sure we have understanding. As y=
ou say in the first paragraph, a peer would never get messages that it does n=
ot understand, so there is no chance that missing a protocol change would ma=
tter.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">In case it=E2=80=99s n=
ot understood, version negotiation provides each peer with the maximum suppo=
rted protocol version of the other. Once complete both have negotiated to th=
e highest common version. No message not supported at that version may be se=
nt by either.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">If the protoc=
ol was to accept *any* message traffic then it will cease to be a protocol. P=
eople will drop in their changes without obtaining broad support, and peers w=
ill evolve to the point of no longer being peers. They won=E2=80=99t speak t=
he same language and the =E2=80=9Cnetwork=E2=80=9D will be little more than a=
 broadcast transport, broadcasting all traffic to all peers, whether it=E2=80=
=99s for them or not.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Peopl=
e need to either build support or build a distinct network. That=E2=80=99s t=
he actual coordination issue, which is inherent to protocol development.</di=
v><div dir=3D"ltr"><br></div><div dir=3D"ltr">Best,</div><div dir=3D"ltr">e<=
/div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Aug 17, 2020, at 13:4=
0, Suhas Daftuar &lt;sdaftuar@gmail.com&gt; wrote:<br><br></blockquote></div=
><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr">Hi Eric,<div><b=
r></div><div>Thanks for your response.&nbsp; If I understand correctly, you'=
re suggesting that in the future we do the same as what was done in BIP 339,=
 of accompanying new messages (which are optional) with a protocol version b=
ump, so that network clients are never reading unknown messages from a peer (=
and can be free to disconnect a peer for sending an unknown message)?</div><=
div><br></div><div>I think that works fine, so if indeed there will be softw=
are that will expect things to operate this way then I can withdraw the sugg=
estion I've made in this thread.&nbsp; However I wanted to clarify that this=
 is what you suggest, because there is another downside to this approach (be=
yond the sequential nature of sequence numbers that you mention) -- if a sof=
tware implementation misses a proposed new protocol upgrade, and thus fails t=
o parse (and ignore) some proposed new message, the result can be a network s=
plit down the road as incompatible clients get slowly upgraded over time.&nb=
sp;</div><div><br></div><div>I think this coordination cost is something to b=
e concerned about -- for instance, the lack of response to my wtxid-relay pr=
oposal made me wonder if other software would be implementing something to a=
ccount for the new message that proposal introduces (for clients with versio=
n &gt;=3D 70016).&nbsp; It's reasonable for people to be busy and miss thing=
s like this, and I think it's worth considering whether there's a safer way f=
or us to deploy changes.</div><div><br></div><div>That said, I don't think t=
his coordination cost is unbearable, so as long as we have a process for mak=
ing p2p protocol improvements I'm not too worried about what mechanism we us=
e.&nbsp; So if this concern over coordination of changes doesn't sway you, I=
 think we can continue to just bump protocol version at the same time as dep=
loying new messages, as we have been doing, and hope that we don't run into p=
roblems down the road.&nbsp;&nbsp;</div><div><br></div><div>If I have misund=
erstood how you think we should be making future protocol changes, please le=
t me know.</div><div><br></div><div>Thanks,</div><div>Suhas</div><div><br></=
div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil &lt;<a href=3D=
"mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil.org</a>&gt; wrote:<=
br></div><blockquote class=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"auto">=
<div dir=3D"ltr"><div dir=3D"ltr">A requirement to ignore unknown (invalid) m=
essages is not only a protocol breaking change but poor protocol design. The=
 purpose of version negotiation is to determine the set of valid messages. C=
hanges to version negotiation itself are very problematic.</div><div dir=3D"=
ltr"><br></div><div dir=3D"ltr">The only limitation presented by versioning i=
s that the system is sequential. As such, clients that do not wish to implem=
ent (or operators who do not wish to enable) them are faced with a problem w=
hen wanting to support later features. This is resolvable by making such fea=
tures optional at the new protocol level. This allows each client to limit i=
ts communication to the negotiated protocol, and allows ignoring of known bu=
t unsupported/disabled features.</div><div dir=3D"ltr"><br></div><div dir=3D=
"ltr">Sorry I missed your earlier post. Been distracted for a while.</div><d=
iv dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div dir=3D"ltr"><br></div>=
<div dir=3D"ltr"><br></div></div><div dir=3D"ltr"><blockquote type=3D"cite">=
On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:<br><br></blockquote></div><blockquote t=
ype=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr">Hi,<div><br></div><d=
iv>Back in February I posted a proposal for WTXID-based transaction relay[1]=
 (now known as BIP 339), which included a proposal for feature negotiation t=
o take place prior to the VERACK message being received by each side.&nbsp; I=
n my email to this list, I had asked for feedback as to whether that proposa=
l was problematic, and didn't receive any responses.</div><div><br></div><di=
v>Since then, the implementation&nbsp;of BIP 339 has been merged into Bitcoi=
n Core, though it has not yet been released.</div><div><br></div><div>In thi=
nking about the mechanism used there, I thought it would&nbsp;be helpful to c=
odify in a BIP the idea that Bitcoin network clients should ignore unknown m=
essages received before a VERACK.&nbsp; A draft of my proposal is available h=
ere[2].</div><div><br></div><div>I presume that software upgrading past prot=
ocol version 70016 was already planning to either implement BIP 339, or igno=
re the wtxidrelay message proposed in BIP 339 (if not, then this would creat=
e network split concerns in the future -- so I hope that someone would speak=
 up if this were a problem).&nbsp; When we propose future protocol upgrades t=
hat would benefit from feature negotiation at the time of connection, I thin=
k it would be nice to be able to use the same method as proposed in BIP 339,=
 without even needing to bump the protocol version.&nbsp; So having an under=
standing that this is the standard of how other network clients operate woul=
d be helpful.</div><div><br></div><div>If, on the other hand, this is proble=
matic for some reason, I look forward to hearing that as well, so that we ca=
n be careful about how we deploy future p2p changes to avoid disruption.</di=
v><div><br></div><div>Thanks,</div><div>Suhas Daftuar</div><div><br></div><d=
iv>[1]&nbsp;<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-d=
ev/2020-February/017648.html" target=3D"_blank">https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2020-February/017648.html</a><br></div><div><br>=
</div><div>[2]&nbsp;<a href=3D"https://github.com/sdaftuar/bips/blob/2020-08=
-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki" targ=
et=3D"_blank">https://github.com/sdaftuar/bips/blob/2020-08-generalized-feat=
ure-negotiation/bip-p2p-feature-negotiation.mediawiki</a></div></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><=
/span><br><span><a href=3D"https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/l=
istinfo/bitcoin-dev</a></span><br></div></blockquote></div></blockquote></di=
v>
</div></blockquote></body></html>=

--Apple-Mail-5EE96465-E05B-480D-B8C1-43DC55EBB4B7--