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
|
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 CA5B1C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 20:47:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id A4502204DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 20:47:56 +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 kuPj1YPVnvSW
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 20:47:54 +0000 (UTC)
X-Greylist: delayed 00:45:48 by SQLgrey-1.7.6
Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com
[209.85.219.66])
by silver.osuosl.org (Postfix) with ESMTPS id B156A20347
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 20:47:54 +0000 (UTC)
Received: by mail-qv1-f66.google.com with SMTP id v1so5030825qvn.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 13:47:54 -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:in-reply-to:to;
bh=LYRWL/XVPo2vIoaDJ9XUcnDY3oPgoSvkRotGYd+Mfuw=;
b=ty+uR4wFVw0fzoyNudhlmq2unT5eLr9U8TG5+jVwgJctgobE5gUVRlqP3rqpy1tgxl
1zx4k28m6BPNjDWkHEPXdczaHV/GziBZysIGkvgwanyIwSotdF1OcQbWk55FRmcVEvg6
w58bAMpiwOqIbtrlSUQ2f47YQQ63SEPHIY0FfzgEy6HyMqe/XNS8zIC0ks5pU0o+dB23
JmeJjOU1kHfJB8lf9ccjM9BuVyQYitjTV2YtWw5nM/L+JbdDva3JuPSVrtckdgxnz1Ix
OU4voFvbATDw0zknlavADqa1L6IW9xkukplaXrRvVpj9+9XXI1aT4T9K5zU/0uJyRnkJ
3G9g==
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:in-reply-to:to;
bh=LYRWL/XVPo2vIoaDJ9XUcnDY3oPgoSvkRotGYd+Mfuw=;
b=fj4bEpYJrGg9nncv/nyc1yU71h9sUQRcjj44iqFbeJGAvY1TmurPVo757WblzFcmCg
8GG5XZPcQ6KIIoIF75x9e5gHvas6IoJD/rg/wV1vWKy5j3wNqyC5mmGpdweoQGZEpoZG
hVZ28vwag3AyYQ1Y0M3N2p1pI8Q3z1Ibi6Ndmj6XBNex34jNLcAvCu09xngSOMBxH+c5
LsYeTEyiIulXjRoAyzEI8CnS4vhUyp9Fhxrs53Wj94qhevOi9vzwXo6TOBAtJNydbn2j
bxEs+yDYOrLoD/6xEDQgrb5hj93xzXIiDA2Gpu4m3MyijE/j+XcA4xHsx6Q8p6aMEsxj
Z9JA==
X-Gm-Message-State: AOAM531HYd0s7BL8aMEHG8mlC/eq1fX5GkZTCUN3JMtl1v2g8aGpHnNz
je8lev7qA9GmyFuyQyHRnpSLSI7fRVpCZw==
X-Google-Smtp-Source: ABdhPJxUGul8XWZjahXq/JKjAlJ3q9y2Y3FVnMIiVhHwSOrKDyeH5UIZDgZ/nZQqEGZFCKkMkaDzUA==
X-Received: by 2002:a17:902:c206:: with SMTP id
6mr1479352pll.169.1597604817043;
Sun, 16 Aug 2020 12:06:57 -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 r28sm16193587pfg.158.2020.08.16.12.06.56
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 16 Aug 2020 12:06:56 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 16 Aug 2020 12:06:55 -0700
Message-Id: <C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
References: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
In-Reply-To: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (17G68)
X-Mailman-Approved-At: Sun, 16 Aug 2020 21:26:28 +0000
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: Sun, 16 Aug 2020 20:47:56 -0000
--Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
A requirement to ignore unknown (invalid) messages is not only a protocol br=
eaking change but poor protocol design. The purpose of version negotiation i=
s to determine the set of valid messages. Changes to version negotiation its=
elf 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 wi=
sh 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 proto=
col level. This allows each client to limit its communication to the negotia=
ted protocol, and allows ignoring of known but 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@list=
s.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 to t=
ake place prior to the VERACK message being received by each side. In my em=
ail to this list, I had asked for feedback as to whether that proposal was p=
roblematic, and didn't receive any responses.
>=20
> Since then, the implementation of BIP 339 has been merged into Bitcoin Cor=
e, though it has not yet been released.
>=20
> In thinking about the mechanism used there, I thought it would be helpful t=
o codify in a BIP the idea that Bitcoin network clients should ignore unknow=
n messages received before a VERACK. A draft of my proposal is available he=
re[2].
>=20
> I presume that software upgrading past protocol version 70016 was already p=
lanning to either implement BIP 339, or ignore the wtxidrelay message propos=
ed in BIP 339 (if not, then this would create network split concerns in the f=
uture -- so I hope that someone would speak up if this were a problem). Whe=
n we propose future protocol upgrades that would benefit from feature negoti=
ation at the time of connection, I think it would be nice to be able to use t=
he same method as proposed in BIP 339, without even needing to bump the prot=
ocol version. So having an understanding that this is the standard of how o=
ther network clients operate would be helpful.
>=20
> If, on the other hand, this is problematic for some reason, I look forward=
to hearing that as well, so that we can be careful about how we deploy futu=
re p2p changes to avoid disruption.
>=20
> Thanks,
> Suhas Daftuar
>=20
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/=
017648.html
>=20
> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-nego=
tiation/bip-p2p-feature-negotiation.mediawiki
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796
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"><div dir=3D"ltr">A require=
ment to ignore unknown (invalid) messages is not only a protocol breaking ch=
ange but poor protocol design. The purpose of version negotiation is to dete=
rmine the set of valid messages. Changes to version negotiation itself are v=
ery problematic.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">The only l=
imitation 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 enab=
le) them are faced with a problem when wanting to support later features. Th=
is is resolvable by making such features optional at the new protocol level.=
This allows each client to limit its communication to the negotiated protoc=
ol, and allows ignoring of known but unsupported/disabled features.</div><di=
v dir=3D"ltr"><br></div><div dir=3D"ltr">Sorry I missed your earlier post. B=
een 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></div></div><div dir=
=3D"ltr"><blockquote type=3D"cite">On Aug 14, 2020, at 12:28, Suhas Daftuar v=
ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<br><br><=
/blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div d=
ir=3D"ltr">Hi,<div><br></div><div>Back in February I posted a proposal for W=
TXID-based transaction relay[1] (now known as BIP 339), which included a pro=
posal for feature negotiation to take place prior to the VERACK message bein=
g received by each side. In my email to this list, I had asked for fee=
dback as to whether that proposal was problematic, and didn't receive any re=
sponses.</div><div><br></div><div>Since then, the implementation of BIP=
339 has been merged into Bitcoin Core, though it has not yet been released.=
</div><div><br></div><div>In thinking about the mechanism used there, I thou=
ght it would be helpful to codify in a BIP the idea that Bitcoin networ=
k clients should ignore unknown messages received before a VERACK. A d=
raft of my proposal is available here[2].</div><div><br></div><div>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 3=
39 (if not, then this would create network split concerns in the future -- s=
o I hope that someone would speak up if this were a problem). When we p=
ropose future protocol upgrades that would benefit from feature negotiation a=
t the time of connection, I think it would be nice to be able to use the sam=
e method as proposed in BIP 339, without even needing to bump the protocol v=
ersion. So having an understanding that this is the standard of how ot=
her network clients operate would be helpful.</div><div><br></div><div>If, o=
n the other hand, this is problematic for some reason, I look forward to hea=
ring that as well, so that we can be careful about how we deploy future p2p c=
hanges to avoid disruption.</div><div><br></div><div>Thanks,</div><div>Suhas=
Daftuar</div><div><br></div><div>[1] <a href=3D"https://lists.linuxfou=
ndation.org/pipermail/bitcoin-dev/2020-February/017648.html">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html</a><br></=
div><div><br></div><div>[2] <a href=3D"https://github.com/sdaftuar/bips=
/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.me=
diawiki">https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-n=
egotiation/bip-p2p-feature-negotiation.mediawiki</a></div></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=
--Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796--
|