Date: Mon, 13 Feb 2017 13:04:15 +0000
In-Reply-To: <0983c823-e517-2821-1398-24bc7467b364@voskuil.org>
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
	<CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
	<dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
	<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 <eric@voskuil.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <D863B756-565E-46A2-9731-2B8133653823@mattcorallo.com>
Cc: libbitcoin@lists.dyne.org
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
Precedence: list

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 <eric@voskuil=2Eo=
rg> 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
><eric@voskuil=2Eorg> 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