1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D3CC3910
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 10:33:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 20E10FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 10:33:32 +0000 (UTC)
Received: from [26.83.158.48] (unknown [172.56.6.130])
by mail.bluematt.me (Postfix) with ESMTPSA id 3AA231371DB;
Mon, 13 Feb 2017 10:33:26 +0000 (UTC)
Date: Mon, 13 Feb 2017 10:16:13 +0000
In-Reply-To: <dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
<CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
<dde5349d-c430-ad57-30c7-77954ff1a94d@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>,
Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <424C9E40-0B90-46A6-9C5E-30AE3E84E119@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: libbitcoin@lists.dyne.org
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 10:33:33 -0000
For the reasons Pieter listed, an explicit part of our version handshake an=
d protocol negotiation is the exchange of otherwise-ignored messages to set=
up optional features=2E
Peers that do not support this ignore such messages, just as if they had i=
ndicated 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 cl=
early allowing old nodes to communicate just fine=2E
On February 13, 2017 10:36:21 AM GMT+01:00, Eric Voskuil via bitcoin-dev <=
bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>On 02/13/2017 12:47 AM, Pieter Wuille wrote:
>> On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev"
>> <bitcoin-dev@lists=2Elinuxfoundation=2Eorg wrote:
>>=20
>> The BIP151 proposal states:
>>=20
>> > This proposal is backward compatible=2E Non-supporting peers will
>ignore
>> the encinit messages=2E
>>=20
>> This statement is incorrect=2E Sending content that existing nodes
>do not
>> expect is clearly an incompatibility=2E An implementation that
>ignores
>> invalid content leaves itself wide open to DOS attacks=2E The
>version
>> handshake must be complete before the protocol level can be
>determined=2E
>> While it may be desirable for this change to precede the version
>> handshake it cannot be described as backward compatible=2E
>>=20
>> The worst possible effect of ignoring unknown messages is a waste of
>> downstream bandwidth=2E The same is already possible by being sent addr
>> messages=2E
>>=20
>> Using the protocol level requires a strict linear progression of
>> (allowed) network protocol features, which I expect to become harder
>and
>> harder to maintain=2E
>>=20
>> Using otherwise ignored messages for determining optional features is
>> elegant, simple and opens no new attack vectors=2E I think it's very
>much
>> preferable over continued increments of the protocol version=2E
>
>As I said, it *may* be desirable, but it is *not* backward compatible,
>and you do not actually dispute that above=2E
>
>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=2E All adopted BIPs to date have followed this
>pattern=2E This is not the same and it is not helpful to imply that it is
>just following that pattern=2E
>
>As for DOS, waste of bandwidth is not something to be ignored=2E If a
>peer
>is flooding a node with addr message the node can manage it because it
>understands the semantics of addr messages=2E If a node is required to
>allow any message that it cannot understand it has no recourse=2E It
>cannot determine whether it is under attack or if the behavior is
>correct and for proper continued operation must be ignored=2E
>
>This approach breaks any implementation that validates traffic, which
>is
>clearly correct behavior given the existence of the version handshake=2E
>Your comments make it clear that this is a *change* in network behavior
>- essentially abandoning the version handshake=2E Whether is is harder to
>maintain is irrelevant to the question of whether it is a break with
>existing protocol=2E
>
>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=2E 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=2E
>
>e
|
