Date: Mon, 13 Feb 2017 10:16:13 +0000
In-Reply-To: <dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
	<CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
	<dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Eric Voskuil <eric@voskuil.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <424C9E40-0B90-46A6-9C5E-30AE3E84E119@mattcorallo.com>
Cc: libbitcoin@lists.dyne.org
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
Precedence: list

For the reasons Pieter listed, an explicit part of our version handshake an=
d protocol negotiation is the exchange of otherwise-ignored messages to set=
 up optional features=2E

Peers that do not support this ignore such messages, just as if they had i=
ndicated they wouldn't support it, see, eg BIP 152's handshake=2E Not sure =
why you consider this backwards incompatible, as I would say it's pretty cl=
early allowing old nodes to communicate just fine=2E

On February 13, 2017 10:36:21 AM GMT+01:00, Eric Voskuil via bitcoin-dev <=
bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>On 02/13/2017 12:47 AM, Pieter Wuille wrote:
>> On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev"
>> <bitcoin-dev@lists=2Elinuxfoundation=2Eorg wrote:
>>=20
>>     The BIP151 proposal states:
>>=20
>>     > This proposal is backward compatible=2E Non-supporting peers will
>ignore
>>     the encinit messages=2E
>>=20
>>     This statement is incorrect=2E Sending content that existing nodes
>do not
>>     expect is clearly an incompatibility=2E An implementation that
>ignores
>>     invalid content leaves itself wide open to DOS attacks=2E The
>version
>>     handshake must be complete before the protocol level can be
>determined=2E
>>     While it may be desirable for this change to precede the version
>>     handshake it cannot be described as backward compatible=2E
>>=20
>> The worst possible effect of ignoring unknown messages is a waste of
>> downstream bandwidth=2E The same is already possible by being sent addr
>> messages=2E
>>=20
>> Using the protocol level requires a strict linear progression of
>> (allowed) network protocol features, which I expect to become harder
>and
>> harder to maintain=2E
>>=20
>> Using otherwise ignored messages for determining optional features is
>> elegant, simple and opens no new attack vectors=2E I think it's very
>much
>> preferable over continued increments of the protocol version=2E
>
>As I said, it *may* be desirable, but it is *not* backward compatible,
>and you do not actually dispute that above=2E
>
>There are other control messages that qualify as "optional messages"
>but
>these are only sent if the peer is at a version to expect them -
>explicit in their BIPs=2E All adopted BIPs to date have followed this
>pattern=2E This is not the same and it is not helpful to imply that it is
>just following that pattern=2E
>
>As for DOS, waste of bandwidth is not something to be ignored=2E If a
>peer
>is flooding a node with addr message the node can manage it because it
>understands the semantics of addr messages=2E If a node is required to
>allow any message that it cannot understand it has no recourse=2E It
>cannot determine whether it is under attack or if the behavior is
>correct and for proper continued operation must be ignored=2E
>
>This approach breaks any implementation that validates traffic, which
>is
>clearly correct behavior given the existence of the version handshake=2E
>Your comments make it clear that this is a *change* in network behavior
>- essentially abandoning the version handshake=2E Whether is is harder to
>maintain is irrelevant to the question of whether it is a break with
>existing protocol=2E
>
>If you intend for the network to abandon the version handshake and/or
>promote changes that break it I propose that you write up this new
>behavior as a BIP and solicit community feedback=2E There are a lot of
>devices connected to the network and it would be irresponsible to break
>something as fundamental as the P2P protocol handshake because you have
>a feeling it's going to be hard to maintain=2E
>
>e