From: Eric Voskuil <eric@voskuil•org>
To: Jonas Schnelli <dev@jonasschnelli•ch>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
Date: Mon, 13 Feb 2017 02:30:14 -0800 [thread overview]
Message-ID: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org> (raw)
In-Reply-To: <ff7c24ba-7c70-efaf-a319-b1aebfd8a3bd@jonasschnelli.ch>
[-- Attachment #1: Type: text/plain, Size: 2960 bytes --]
On 02/13/2017 02:07 AM, Jonas Schnelli via bitcoin-dev wrote:
>> All adopted BIPs to date have followed this
>> pattern. This is not the same and it is not helpful to imply that it is
>> just following that pattern.
>
> Look at feefilter BIP 133
> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility)
> or sendheaders BIP130
> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backward-compatibility)
> Isn't it the same there?
No. This is what I was referring to. These messages are enabled by
protocol version. If they are received by a node below the version at
which they are activated, they are unknown messages, implying an invalid
peer. The above messages cannot be sent until *after* the version is
negotiated. BIP151 violates this rule by allowing the new control
message to be sent *before* the version handshake.
> Once BIP151 is implemented, it would make sense to bump the protocol
> version, but this needs to be done once this has been
> implemented/deployed.
There are already nodes out there breaking connections based on the BIP.
> Or do I make a mistake somewhere?
Yes, the ordering of the messages. New messages can only be added after
the handshake negotiates the higher version. Otherwise the handshake is
both irrelevant (as Pieter is implying) and broken (for all existing
protocol versions).
>> As for DOS, waste of bandwidth is not something to be ignored. If a peer
>> is flooding a node with addr message the node can manage it because it
>> understands the semantics of addr messages. If a node is required to
>> allow any message that it cannot understand it has no recourse. It
>> cannot determine whether it is under attack or if the behavior is
>> correct and for proper continued operation must be ignored.
> How do you threat any other not known message types?
You may be more familiar with non-validating peers. If a message type is
not known it is an invalid message and the peer is immediately dropped.
We started seeing early drops in handshakes with bcoin nodes because of
this issue.
> Any peer can send you any type of message anytime.
Sure, a peer can do what it wants. It can send photos. But I'm not sure
what makes you think it would be correct to maintain the connection when
an *invalid* message is received.
> Why would your implementation how you threat unknown messages be
different for messages specified in BIP151?
Because it properly validates the protocol.
More than that it supports a configurable protocol range. So by setting
the min protocol (below which the node won't connect) and the max
protocol (at which it desires to connect) we can observe the behavior of
the network at any protocol levels (currently between 31402 and 70013).
This is very helpful for a development stack as it allows one to easily
test against each protocol level that one wishes to support.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2017-02-13 10:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 5:18 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 [this message]
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
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=638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dev@jonasschnelli$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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