MIME-Version: 1.0
In-Reply-To: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Mon, 13 Feb 2017 00:47:38 -0800
Message-ID: <CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=001a114b2e44ed1f950548657f1f
Cc: libbitcoin@lists.dyne.org
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
Precedence: list

--001a114b2e44ed1f950548657f1f
Content-Type: text/plain; charset=UTF-8

On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

The BIP151 proposal states:

> This proposal is backward compatible. Non-supporting peers will ignore
the encinit messages.

This statement is incorrect. Sending content that existing nodes do not
expect is clearly an incompatibility. An implementation that ignores
invalid content leaves itself wide open to DOS attacks. The version
handshake must be complete before the protocol level can be determined.
While it may be desirable for this change to precede the version
handshake it cannot be described as backward compatible.


The worst possible effect of ignoring unknown messages is a waste of
downstream bandwidth. The same is already possible by being sent addr
messages.

Using the protocol level requires a strict linear progression of (allowed)
network protocol features, which I expect to become harder and harder to
maintain.

Using otherwise ignored messages for determining optional features is
elegant, simple and opens no new attack vectors. I think it's very much
preferable over continued increments of the protocol version.

-- 
Pieter

--001a114b2e44ed1f950548657f1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Feb 12, 2017 23:58, &quot;Eric Voskuil via bitcoin-dev&quot; &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><blockquote c=
lass=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">The BIP151 proposal states:<br>
<br>
&gt; This proposal is backward compatible. Non-supporting peers will ignore=
<br>
the encinit messages.<br>
<br>
This statement is incorrect. Sending content that existing nodes do not<br>
expect is clearly an incompatibility. An implementation that ignores<br>
invalid content leaves itself wide open to DOS attacks. The version<br>
handshake must be complete before the protocol level can be determined.<br>
While it may be desirable for this change to precede the version<br>
handshake it cannot be described as backward compatible.</blockquote></div>=
</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">The worst possibl=
e effect of ignoring unknown messages is a waste of downstream bandwidth. T=
he same is already possible by being sent addr messages.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Using the protocol level requires a strict=
 linear progression of (allowed) network protocol features, which I expect =
to become harder and harder to maintain.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Using otherwise ignored messages for determining optional =
features is elegant, simple and opens no new attack vectors. I think it&#39=
;s very much preferable over continued increments of the protocol version.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">--=C2=A0</div><div dir=
=3D"auto">Pieter</div><div dir=3D"auto"><br></div><div dir=3D"auto"></div><=
div dir=3D"auto"><div class=3D"gmail_extra"><br></div></div></div>

--001a114b2e44ed1f950548657f1f--