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
|
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 D5E6EC07FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2020 20:40:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id C1E60866A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2020 20:40:15 +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 rh3Kj0NIIUv0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2020 20:40:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com
[209.85.166.45])
by whitealder.osuosl.org (Postfix) with ESMTPS id 8BB51866AB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2020 20:40:14 +0000 (UTC)
Received: by mail-io1-f45.google.com with SMTP id b17so18981844ion.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2020 13:40:14 -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=eS9WP2zKacAbvbnn7LUcBIqIyC54z7dXX8M9KonAs8Q=;
b=rq5Wr50i7rzeVoL5i4889DkfmyTdn2OU84EXobHQbjIgbsQMI71mC5QHBgAlCLL7KD
jVgTScWLqC+9SuZQx3pK4OlPNiM7lq07D3ftnGs6KHgiG1LDnx/Xeby2PI1nygw+Ig0j
1Yf0PwtnSFZ32RvTGVeFfR1ISfBtV72RUqfx460BLVcEyn6o6Ufc3U86R0+zom2qKIA5
onX/hzwOdha2RnwOne2tEGVwNnOhpS8kWugz9IFMP9OBpwjSQ4LJmWUkPvZqqgBcrHt+
hMjTH6qCqmiN40EUFQy3Bxu4gHWr68n48xFddgHng/A5y+9Mqwng8diT/f1+pNflOFkq
tpDQ==
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=eS9WP2zKacAbvbnn7LUcBIqIyC54z7dXX8M9KonAs8Q=;
b=szV6zuddiAYu2zS0eQtrUKzgeFZdbkSNaJXfvjmtNnMyNIye11w49uiTPqWfNNDGAF
54qQMHUv7t/Wh79son6w2rlLXZew2cYyCZHvJWehMP6jii3LEiWfeBuPfl5nsMIk3H0Y
fpvIHTq1ML4uilU4SVWhswR8iTQiAc4JM77s4/XlOnRLnnxmTEu6ULs2p9FsKY5V76DU
9629fwQivGN7C6lXsrpvF9QEfiP0f8YFzLH+OWkFCH1gWi7wurm4nbHprSYEi5nZZXew
ofLgGZUtt4vslq4cVzLmiQkJHwbSo0tFZcIPiZu8iTq7JLSpF0kiSyzEywNs4D1Ouqsy
s6HA==
X-Gm-Message-State: AOAM532FndvDANc8oDupLRMmDwAEwBN4h8t5zhH/NPvpoZp6ng9odKJd
5EwyI205iGZyYtO+IX7/gTyR2DavSa1rOmMFTOA=
X-Google-Smtp-Source: ABdhPJzI6vQjuTofBN4ifVrlixy/PiSkXCoWne6LptM+tRIHfa/CzEj0BaEYB5Tz9lWv6FzsGORFsqfxHMJXT7xSzwQ=
X-Received: by 2002:a02:a04d:: with SMTP id f13mr16199999jah.112.1597696813568;
Mon, 17 Aug 2020 13:40:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
<C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
In-Reply-To: <C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Mon, 17 Aug 2020 16:40:02 -0400
Message-ID: <CAFp6fsH==PJ38vGvCGUr3AVS8XmQEjvLkNaopAhu0vY7xQjgAw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="00000000000008178705ad18c767"
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 20:40:15 -0000
--00000000000008178705ad18c767
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Eric,
Thanks for your response. 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
bump, 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)?
I think that works fine, so if indeed there will be software that will
expect things to operate this way then I can withdraw the suggestion I've
made in this thread. However I wanted to clarify that this is what you
suggest, because there is another downside to this approach (beyond the
sequential nature of sequence numbers that you mention) -- if a software
implementation misses a proposed new protocol upgrade, and thus fails to
parse (and ignore) some proposed new message, the result can be a network
split down the road as incompatible clients get slowly upgraded over time.
I think this coordination cost is something to be concerned about -- for
instance, the lack of response to my wtxid-relay proposal made me wonder if
other software would be implementing something to account for the new
message that proposal introduces (for clients with version >=3D 70016). It=
's
reasonable for people to be busy and miss things like this, and I think
it's worth considering whether there's a safer way for us to deploy changes=
.
That said, I don't think this coordination cost is unbearable, so as long
as 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 changes doesn't sway you, I think we can continue to just bump protocol
version at the same time as deploying new messages, as we have been doing,
and hope that we don't run into problems down the road.
If I have misunderstood how you think we should be making future protocol
changes, please let me know.
Thanks,
Suhas
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
> negotiation is to determine the set of valid messages. Changes to version
> negotiation itself are very problematic.
>
> The only limitation presented by versioning is that the system is
> sequential. 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 option=
al
> at the new protocol level. This allows each client to limit its
> communication to the negotiated protocol, and allows ignoring of known bu=
t
> unsupported/disabled features.
>
> Sorry I missed your earlier post. Been distracted for a while.
>
> e
>
>
> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> =EF=BB=BF
> Hi,
>
> 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
> to take place prior to the VERACK message being received by each side. I=
n
> my email to this list, I had asked for feedback as to whether that propos=
al
> was problematic, and didn't receive any responses.
>
> Since then, the implementation of BIP 339 has been merged into Bitcoin
> Core, though it has not yet been released.
>
> In thinking about the mechanism used there, I thought it would be helpful
> to codify in a BIP the idea that Bitcoin network clients should ignore
> unknown messages received before a VERACK. A draft of my proposal is
> available here[2].
>
> I presume that software upgrading past protocol version 70016 was already
> planning to either implement BIP 339, or ignore the wtxidrelay message
> proposed in BIP 339 (if not, then this would create network split concern=
s
> in the future -- so I hope that someone would speak up if this were a
> problem). When we propose future protocol upgrades that would benefit fr=
om
> feature negotiation at the time of connection, I think it would be nice t=
o
> be able to use the same method as proposed in BIP 339, without even needi=
ng
> to bump the protocol version. So having an understanding that this is th=
e
> standard of how other network clients operate would be helpful.
>
> If, on the other hand, this is problematic for some reason, I look forwar=
d
> to hearing that as well, so that we can be careful about how we deploy
> future p2p changes to avoid disruption.
>
> Thanks,
> Suhas Daftuar
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017=
648.html
>
> [2]
> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotia=
tion/bip-p2p-feature-negotiation.mediawiki
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--00000000000008178705ad18c767
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Eric,<div><br></div><div>Thanks for your response.=C2=
=A0 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 (whic=
h are optional) with a protocol version bump, so that network clients are n=
ever 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 software that will expect things to=
operate this way then I can withdraw the suggestion I've made in this =
thread.=C2=A0 However I wanted to clarify that this is what you suggest, be=
cause there is another downside to this approach (beyond the sequential nat=
ure of sequence numbers that you mention) -- if a software implementation m=
isses a proposed new protocol upgrade, and thus fails to parse (and ignore)=
some proposed new message, the result can be a network split down the road=
as incompatible clients get slowly upgraded over time.=C2=A0</div><div><br=
></div><div>I think this coordination cost is something to be concerned abo=
ut -- for instance, the lack of response to my wtxid-relay proposal made me=
wonder if other software would be implementing something to account for th=
e new message that proposal introduces (for clients with version >=3D 70=
016).=C2=A0 It's reasonable for people to be busy and miss things like =
this, and I think it's worth considering whether there's a safer wa=
y for us to deploy changes.</div><div><br></div><div>That said, I don't=
think this coordination cost is unbearable, so as long as we have a proces=
s for making p2p protocol improvements I'm not too worried about what m=
echanism we use.=C2=A0 So if this concern over coordination of changes does=
n't sway you, I think we can continue to just bump protocol version at =
the same time as deploying new messages, as we have been doing, and hope th=
at we don't run into problems down the road.=C2=A0=C2=A0</div><div><br>=
</div><div>If I have misunderstood how you think we should be making future=
protocol changes, please let me know.</div><div><br></div><div>Thanks,</di=
v><div>Suhas</div><div><br></div><div><br></div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 16, 2020 at 3:0=
6 PM Eric Voskuil <<a href=3D"mailto:eric@voskuil.org" target=3D"_blank"=
>eric@voskuil.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"auto"><div dir=3D"ltr"><div dir=3D"ltr">A requ=
irement to ignore unknown (invalid) messages is not only a protocol breakin=
g change but poor protocol design. The purpose of version negotiation is to=
determine the set of valid messages. Changes to version negotiation itself=
are very problematic.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">The=
only limitation presented by versioning is that the system is sequential. =
As such, clients that do not wish to implement (or operators who do not wis=
h to enable) them are faced with a problem when wanting to support later fe=
atures. This is resolvable by making such features optional at the new prot=
ocol level. This allows each client to limit its communication to the negot=
iated protocol, and allows ignoring of known but unsupported/disabled featu=
res.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Sorry I missed your e=
arlier post. Been distracted for a while.</div><div dir=3D"ltr"><br></div><=
div dir=3D"ltr">e</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></di=
v></div><div dir=3D"ltr"><blockquote type=3D"cite">On Aug 14, 2020, at 12:2=
8, Suhas Daftuar via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a>> wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=
=3D"ltr">=EF=BB=BF<div dir=3D"ltr">Hi,<div><br></div><div>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 to take place prior=
to the VERACK message being received by each side.=C2=A0 In my email to th=
is list, I had asked for feedback as to whether that proposal was problemat=
ic, and didn't receive any responses.</div><div><br></div><div>Since th=
en, the implementation=C2=A0of BIP 339 has been merged into Bitcoin Core, t=
hough it has not yet been released.</div><div><br></div><div>In thinking ab=
out the mechanism used there, I thought it would=C2=A0be helpful to codify =
in a BIP the idea that Bitcoin network clients should ignore unknown messag=
es received before a VERACK.=C2=A0 A draft of my proposal is available here=
[2].</div><div><br></div><div>I presume that software upgrading past protoc=
ol version 70016 was already planning to either implement BIP 339, or ignor=
e 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 spea=
k up if this were a problem).=C2=A0 When we propose future protocol upgrade=
s that would benefit from feature negotiation at the time of connection, I =
think 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.=C2=A0 So having an=
understanding that this is the standard of how other network clients opera=
te would be helpful.</div><div><br></div><div>If, on the other hand, this i=
s problematic for some reason, I look forward to hearing that as well, so t=
hat we can be careful about how we deploy future p2p changes to avoid disru=
ption.</div><div><br></div><div>Thanks,</div><div>Suhas Daftuar</div><div><=
br></div><div>[1]=C2=A0<a href=3D"https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2020-February/017648.html" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html</a><br><=
/div><div><br></div><div>[2]=C2=A0<a href=3D"https://github.com/sdaftuar/bi=
ps/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation=
.mediawiki" target=3D"_blank">https://github.com/sdaftuar/bips/blob/2020-08=
-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki</a><=
/div></div>
<span>_______________________________________________</span><br><span>bitco=
in-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a></span><br><span><a href=3D"https://lists.linuxfoundation.org/mailman/lis=
tinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a></span><br></div></blockquote></div></blockquot=
e></div>
--00000000000008178705ad18c767--
|