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 287F59B9 for ; Mon, 13 Feb 2017 13:14:17 +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 6032F14D for ; Mon, 13 Feb 2017 13:14:16 +0000 (UTC) Received: from [100.150.167.205] (unknown [172.56.12.208]) by mail.bluematt.me (Postfix) with ESMTPSA id 79D8013761C; Mon, 13 Feb 2017 13:14:12 +0000 (UTC) Date: Mon, 13 Feb 2017 13:04:15 +0000 In-Reply-To: <0983c823-e517-2821-1398-24bc7467b364@voskuil.org> References: <424C9E40-0B90-46A6-9C5E-30AE3E84E119@mattcorallo.com> <9ca02a65-23df-5eb4-f9bd-7e05b54ec4ea@voskuil.org> <9ECDD902-1D2C-4500-8FC2-4DADF46E4318@mattcorallo.com> <0983c823-e517-2821-1398-24bc7467b364@voskuil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Eric Voskuil , Bitcoin Protocol Discussion , Pieter Wuille From: Matt Corallo Message-ID: 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 13:14:17 -0000 Sorry, I'm still missing it=2E=2E=2E So your claim is that a) ignoring incoming messages of a type you do not r= ecognize is bad, and thus b) we should be disconnecting/banning peers which= send us messages we do not recognize (can you spell out why? Anyone is fre= e to send your host address messages/transactions they are generating/etc/e= tc, we don't ban nodes for such messages, as that would be crazy - why shou= ld we ban a peer for sending us an extra 50 bytes which we ignore?), and th= us c) this would be backwards incompatible with software which does not cur= rently exist? Usually "backwards incompatible" refers to breaking existing software, not= breaking theoretical software=2E Note that, last I heard, BIP 151 is still= a draft, if such software actually exists we can discuss changing it, but = there are real wins in sending these messages before VERSION=2E On February 13, 2017 12:17:11 PM GMT+01:00, Eric Voskuil wrote: >On 02/13/2017 03:11 AM, Matt Corallo wrote: >> I believe many, if not all, of those messages are sent irrespective >of version number=2E > >In the interest of perfect clarity, see your code: > >https://github=2Ecom/bitcoin/bitcoin/blob/master/src/net_processing=2Ecpp= #L1372-L1403 > >Inside of the VERACK handler (i=2Ee=2E after the handshake) there is a pe= er >version test before sending SENDCMPCT (and SENDHEADERS)=2E > >I have no idea where the fee filter message is sent, if it is sent at >all=2E But I have *never* seen any control messages arrive before the >handshake is complete=2E > >> In any case, I fail to see how adding any additional messages which >are ignored by old peers amounts to a lack of backward compatibility=2E > >See preceding messages in this thread, I think it's pretty clearly >spelled out=2E > >e > >> On February 13, 2017 11:54:23 AM GMT+01:00, Eric Voskuil > wrote: >>> On 02/13/2017 02:16 AM, Matt Corallo wrote: >>>> For the reasons Pieter listed, an explicit part of our version >>> handshake and protocol negotiation is the exchange of >otherwise-ignored >>> messages to set up optional features=2E >>> >>> Only if the peer is at the protocol level that allows the message: >>> >>> compact blocks: >>> >>> >https://github=2Ecom/bitcoin/bitcoin/blob/master/src/protocol=2Eh#L217-L2= 42 >>> >>> fee filter: >>> >>> >https://github=2Ecom/bitcoin/bitcoin/blob/master/src/protocol=2Eh#L211-L2= 16 >>> >>> send headers: >>> >>> >https://github=2Ecom/bitcoin/bitcoin/blob/master/src/protocol=2Eh#L204-L2= 10 >>> >>> filters: >>> >>> >https://github=2Ecom/bitcoin/bitcoin/blob/master/src/protocol=2Eh#L170-L1= 96 >>> >>>> Peers that do not support this ignore such messages, just as if >they >>> had indicated 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 clearly allowing old nodes to communicate just fine=2E >>> >>> No, it is not the same as BIP152=2E Control messages apart from BIP151 >>> are >>> not sent until *after* the version is negotiated=2E >>> >>> I assume that BIP151 is different in this manner because it has a >>> desire >>> to negotiate encryption before any other communications, including >>> version=2E >>> >>> e