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>
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
	connections are setup
Precedence: list


--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 &lt;bitcoin-dev@lists.linuxfoundation.org&gt; 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.&nbsp; 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&nbsp;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&nbsp;be helpful to codify in a BIP the idea that Bitcoin networ=
k clients should ignore unknown messages received before a VERACK.&nbsp; 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).&nbsp; 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.&nbsp; 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]&nbsp;<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]&nbsp;<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--