Eric Voskuil [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-13 📝 Original message:On 02/13/2017 12:47 AM, ...
📅 Original date posted:2017-02-13
📝 Original message:On 02/13/2017 12:47 AM, Pieter Wuille wrote:
> On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org wrote:
>
> The BIP151 proposal states:
>
> > This proposal is backward compatible. Non-supporting peers will ignore
> the encinit messages.
>
> This statement is incorrect. Sending content that existing nodes do not
> expect is clearly an incompatibility. An implementation that ignores
> invalid content leaves itself wide open to DOS attacks. The version
> handshake must be complete before the protocol level can be determined.
> While it may be desirable for this change to precede the version
> handshake it cannot be described as backward compatible.
>
> The worst possible effect of ignoring unknown messages is a waste of
> downstream bandwidth. The same is already possible by being sent addr
> messages.
>
> Using the protocol level requires a strict linear progression of
> (allowed) network protocol features, which I expect to become harder and
> harder to maintain.
>
> Using otherwise ignored messages for determining optional features is
> elegant, simple and opens no new attack vectors. I think it's very much
> preferable over continued increments of the protocol version.
As I said, it *may* be desirable, but it is *not* backward compatible,
and you do not actually dispute that above.
There are other control messages that qualify as "optional messages" but
these are only sent if the peer is at a version to expect them -
explicit in their BIPs. 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.
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.
This approach breaks any implementation that validates traffic, which is
clearly correct behavior given the existence of the version handshake.
Your comments make it clear that this is a *change* in network behavior
- essentially abandoning the version handshake. Whether is is harder to
maintain is irrelevant to the question of whether it is a break with
existing protocol.
If you intend for the network to abandon the version handshake and/or
promote changes that break it I propose that you write up this new
behavior as a BIP and solicit community feedback. There are a lot of
devices connected to the network and it would be irresponsible to break
something as fundamental as the P2P protocol handshake because you have
a feeling it's going to be hard to maintain.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170213/21d7d014/attachment.sig>;
📝 Original message:On 02/13/2017 12:47 AM, Pieter Wuille wrote:
> On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org wrote:
>
> The BIP151 proposal states:
>
> > This proposal is backward compatible. Non-supporting peers will ignore
> the encinit messages.
>
> This statement is incorrect. Sending content that existing nodes do not
> expect is clearly an incompatibility. An implementation that ignores
> invalid content leaves itself wide open to DOS attacks. The version
> handshake must be complete before the protocol level can be determined.
> While it may be desirable for this change to precede the version
> handshake it cannot be described as backward compatible.
>
> The worst possible effect of ignoring unknown messages is a waste of
> downstream bandwidth. The same is already possible by being sent addr
> messages.
>
> Using the protocol level requires a strict linear progression of
> (allowed) network protocol features, which I expect to become harder and
> harder to maintain.
>
> Using otherwise ignored messages for determining optional features is
> elegant, simple and opens no new attack vectors. I think it's very much
> preferable over continued increments of the protocol version.
As I said, it *may* be desirable, but it is *not* backward compatible,
and you do not actually dispute that above.
There are other control messages that qualify as "optional messages" but
these are only sent if the peer is at a version to expect them -
explicit in their BIPs. 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.
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.
This approach breaks any implementation that validates traffic, which is
clearly correct behavior given the existence of the version handshake.
Your comments make it clear that this is a *change* in network behavior
- essentially abandoning the version handshake. Whether is is harder to
maintain is irrelevant to the question of whether it is a break with
existing protocol.
If you intend for the network to abandon the version handshake and/or
promote changes that break it I propose that you write up this new
behavior as a BIP and solicit community feedback. There are a lot of
devices connected to the network and it would be irresponsible to break
something as fundamental as the P2P protocol handshake because you have
a feeling it's going to be hard to maintain.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170213/21d7d014/attachment.sig>;