public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Eric Voskuil <eric@voskuil.org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>
Cc: libbitcoin@lists.dyne.org
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
Date: Mon, 13 Feb 2017 13:04:15 +0000	[thread overview]
Message-ID: <D863B756-565E-46A2-9731-2B8133653823@mattcorallo.com> (raw)
In-Reply-To: <0983c823-e517-2821-1398-24bc7467b364@voskuil.org>

Sorry, I'm still missing it...
So your claim is that a) ignoring incoming messages of a type you do not recognize 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 free to send your host address messages/transactions they are generating/etc/etc, we don't ban nodes for such messages, as that would be crazy - why should we ban a peer for sending us an extra 50 bytes which we ignore?), and thus c) this would be backwards incompatible with software which does not currently exist?

Usually "backwards incompatible" refers to breaking existing software, not breaking theoretical software. 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.

On February 13, 2017 12:17:11 PM GMT+01:00, Eric Voskuil <eric@voskuil.org> 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.
>
>In the interest of perfect clarity, see your code:
>
>https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1372-L1403
>
>Inside of the VERACK handler (i.e. after the handshake) there is a peer
>version test before sending SENDCMPCT (and SENDHEADERS).
>
>I have no idea where the fee filter message is sent, if it is sent at
>all. But I have *never* seen any control messages arrive before the
>handshake is complete.
>
>> 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.
>
>See preceding messages in this thread, I think it's pretty clearly
>spelled out.
>
>e
>
>> On February 13, 2017 11:54:23 AM GMT+01:00, Eric Voskuil
><eric@voskuil.org> 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.
>>>
>>> Only if the peer is at the protocol level that allows the message:
>>>
>>> compact blocks:
>>>
>>>
>https://github.com/bitcoin/bitcoin/blob/master/src/protocol.h#L217-L242
>>>
>>> fee filter:
>>>
>>>
>https://github.com/bitcoin/bitcoin/blob/master/src/protocol.h#L211-L216
>>>
>>> send headers:
>>>
>>>
>https://github.com/bitcoin/bitcoin/blob/master/src/protocol.h#L204-L210
>>>
>>> filters:
>>>
>>>
>https://github.com/bitcoin/bitcoin/blob/master/src/protocol.h#L170-L196
>>>
>>>> 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.
>>> Not
>>> sure why you consider this backwards incompatible, as I would say
>it's
>>> pretty clearly allowing old nodes to communicate just fine.
>>>
>>> No, it is not the same as BIP152. Control messages apart from BIP151
>>> are
>>> not sent until *after* the version is negotiated.
>>>
>>> I assume that BIP151 is different in this manner because it has a
>>> desire
>>> to negotiate encryption before any other communications, including
>>> version.
>>>
>>> e


      reply	other threads:[~2017-02-13 13:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13  5:18 [bitcoin-dev] BIP151 protocol incompatibility Eric Voskuil
2017-02-13  8:47 ` Pieter Wuille
2017-02-13  9:36   ` Eric Voskuil
2017-02-13 10:07     ` Jonas Schnelli
2017-02-13 10:30       ` Eric Voskuil
2017-02-13 11:14         ` Jonas Schnelli
2017-02-14 19:54           ` Eric Voskuil
2017-02-14 20:58             ` Jonas Schnelli
2017-02-13 10:16     ` Matt Corallo
2017-02-13 10:54       ` Eric Voskuil
2017-02-13 11:11         ` Matt Corallo
2017-02-13 11:17           ` Eric Voskuil
2017-02-13 13:04             ` Matt Corallo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D863B756-565E-46A2-9731-2B8133653823@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@voskuil.org \
    --cc=libbitcoin@lists.dyne.org \
    --cc=pieter.wuille@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox