Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-13 📝 Original message:Sorry, I'm still missing ...
📅 Original date posted:2017-02-13
📝 Original message: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 at 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 at 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
📝 Original message: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 at 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 at 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