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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 647A392B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 10:30:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7B6412F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 10:30:11 +0000 (UTC)
Received: by mail-pg0-f41.google.com with SMTP id v184so31688627pgv.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 02:30:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to; bh=qvlG9t3JE8G+CIn+Z6Rhmfzg0P+tfgpymJSfxjY8H5Y=;
b=Pjri4XlMwMI7INu37b47lbd6oyDVbk7xpdAhOmXUF/GW4bUclhPodMUj48kM7iQGO6
KRLuOq+mOJcZyVGSNrhUsQfsY5lbieK2OoqoMSzH8npvi3XNh/cpEbVX2eYiDVyMkJXl
FvYTweQjHBGF79dRfGeT0R8e+mcInkwOKTjkYQX3lGgCOnNy+5TWfLn39f1qHKiBpcRq
Z6TQEtI5l/2nqU/N8X2H5pIub5f/cmwUJ8Q6uofraPXqzZbNsoSrEr90XuCQwcE976tt
m/mKA1K7Ng7GsDLobX4lnYe1kx3yc79OBnRDrmoCAKzaomkrRDvmLnTO2zbtINUSmRO8
rWvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to;
bh=qvlG9t3JE8G+CIn+Z6Rhmfzg0P+tfgpymJSfxjY8H5Y=;
b=mRBHrSNmCsb+HWbR30ZNDimAN3TimSlJrDeDQYI+jLBeJKc+aJt0AfTOEeo5qScrB1
v8R9dzUrGYhIESALc8uq6afx0mhPttZB/YHWCbasIHoP2CQ8Uy85EVb5Qdoclj0i8XFH
E29kYrfgwWkYHm5eu0VRmjdVq1s60ZlOOw1PmHFyEGn32/u+VsLJMeuIAKstdMEwBeoR
EZm3fK8mSxfqQNV18BH8y2TEsKlhV46kLqP/ptLkA677ho7PoFAEpeDQ568r9BF5fWdo
4/ejXFs/PRJD+e8ggLbs0gIyZZpbqG1o1TZkRWrLopxs5JRgVObWp10YiyAL9tvUqEWN
FrfA==
X-Gm-Message-State: AMke39nNG0BVy7zg6uXOJvDJdDJI7h1AiBW1aFV7dbEpkPnQ8tR2xefq5jdSG/DDEoLYmA==
X-Received: by 10.98.5.2 with SMTP id 2mr25632527pff.77.1486981811114;
Mon, 13 Feb 2017 02:30:11 -0800 (PST)
Received: from ?IPv6:2601:600:9000:d69e:29fe:db3d:631d:9499?
([2601:600:9000:d69e:29fe:db3d:631d:9499])
by smtp.gmail.com with ESMTPSA id
j78sm20023705pfk.39.2017.02.13.02.30.09
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 13 Feb 2017 02:30:10 -0800 (PST)
To: Jonas Schnelli <dev@jonasschnelli.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
<CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
<dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
<ff7c24ba-7c70-efaf-a319-b1aebfd8a3bd@jonasschnelli.ch>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N0110
Message-ID: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org>
Date: Mon, 13 Feb 2017 02:30:14 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <ff7c24ba-7c70-efaf-a319-b1aebfd8a3bd@jonasschnelli.ch>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="2TI1rbMW2hk2VmT0mJ2vqCVI7xvJqp2Pu"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 13 Feb 2017 11:43:24 +0000
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:30:12 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2TI1rbMW2hk2VmT0mJ2vqCVI7xvJqp2Pu
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 i=
s
>> just following that pattern.
>=20
> Look at feefilter BIP 133
> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backwar=
d-compatibility)
> or sendheaders BIP130
> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backwar=
d-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 pe=
er
>> 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
--2TI1rbMW2hk2VmT0mJ2vqCVI7xvJqp2Pu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJYoYq2AAoJEDzYwH8LXOFOCx0H/38Fl4DL861CEE6cZXE84Aom
qMhuSBiiNEnfZSdHPKLyxbGBb9Wl7rHbqomeM1y2B9fHwgg3ErIGewo1YmJvUAMF
h9JmM566a8CQ7FT4RenZ04esYRTu7VuJZ5Ps2gLEMyWZZAf8mAdIJdTwqId0U7zA
RV7Pd1xfVBjLx3xCcCrnODUebkk7QB/S2DtlFILxe9lild23L/nvurqpC2yk5UU6
9LltFe+zU/rzUaghEMdmHuh1MNqJNIKE2JnB7V+hqMF2f+SPDQALFGRxUfOx7I16
wAxfbHVSwoCMkxwyMTrUIGhk6PmOsKlLkSOWNvgNccFyzlMznLbf7IOqbiRljpE=
=qpCv
-----END PGP SIGNATURE-----
--2TI1rbMW2hk2VmT0mJ2vqCVI7xvJqp2Pu--
|
