From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D3CC3910 for ; Mon, 13 Feb 2017 10:33:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 20E10FE for ; Mon, 13 Feb 2017 10:33:32 +0000 (UTC) Received: from [26.83.158.48] (unknown [172.56.6.130]) by mail.bluematt.me (Postfix) with ESMTPSA id 3AA231371DB; Mon, 13 Feb 2017 10:33:26 +0000 (UTC) Date: Mon, 13 Feb 2017 10:16:13 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Eric Voskuil , Bitcoin Protocol Discussion , Eric Voskuil via bitcoin-dev , Pieter Wuille , Bitcoin Dev From: Matt Corallo Message-ID: <424C9E40-0B90-46A6-9C5E-30AE3E84E119@mattcorallo.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: libbitcoin@lists.dyne.org Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 10:33:33 -0000 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" >> >=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