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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5F17F949
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 11:14:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8213BE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 11:14:04 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id 909F72D006FB; Mon, 13 Feb 2017 12:14:03 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro.local (unknown [213.55.211.10])
by server3 (Postfix) with ESMTPSA id B25C32D00145;
Mon, 13 Feb 2017 12:14:02 +0100 (CET)
To: Eric Voskuil <eric@voskuil.org>,
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>
<638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <e153823d-e38e-b4b6-01d5-b9d981381e01@jonasschnelli.ch>
Date: Mon, 13 Feb 2017 12:14:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="dNnVSQvgskeC9aXb0wsEX5aG6L0aUnxwQ"
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 11:14:05 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--dNnVSQvgskeC9aXb0wsEX5aG6L0aUnxwQ
Content-Type: multipart/mixed; boundary="TDr5xUoebJE8C3VLxT8NxMSHNkHv61GcC";
protected-headers="v1"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <e153823d-e38e-b4b6-01d5-b9d981381e01@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
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>
<638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org>
In-Reply-To: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org>
--TDr5xUoebJE8C3VLxT8NxMSHNkHv61GcC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
>> Look at feefilter BIP 133
>> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backwa=
rd-compatibility)
>> or sendheaders BIP130
>> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backwa=
rd-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 invali=
d
> 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.
This indeed is not ideal for compatibility checks, but increases security=
=2E
I could not find a protocol specification that said communication must
be terminated when messages are transmitted before the version handshake
has been done. I mostly looked into Bitcoin-Cores implementation (which
means also into BitcoinXT/UT, where this is allowed).
Also. BIP151 clearly says that the requesting peer needs to initiate the
encryption (encinit).
In case of light clients not supporting BIP151 connecting to peers
supporting BIP151, there should never be transmission of new message
types specified in BIP151.
>
>> 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=
=2E
It could very likely be possible that the initial responding peer tries
to initiate a encryption session which would mean that BIP151 was not
implemented correctly.
Correct me if I'm wrong please.
>
>> 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).
I could not find evidence of the protocol specification that would
forbid (=3Dterminate connection) such messages and I think allowing
unknown-messages before the version handshake makes the protocol flexible=
=2E
Are there any reasons we should drop peers if they send us unknown, but
correctly formatted p2p packages (magic, checksum, etc.) before the
version handshake, ... but not drop them if we have received unknown
messages after the version handshake?
I can't see that a such spec. would reduce the DOS attack vector?
>
>>> As for DOS, waste of bandwidth is not something to be ignored. If a p=
eer
>>> is flooding a node with addr message the node can manage it because i=
t
>>> 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 i=
s
> 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.
If this had happened, it's very likely because the responding peer tried
to initiate a encryption session which is against BIP151 specs.
>
>> 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 whe=
n
> an *invalid* message is received.
Check:
https://github.com/bitcoin/bitcoin/blob/a06ede9a138d0fb86b0de17c42b936d9f=
e6e2158/src/net_processing.cpp#L2595
I think it was a wise implementation decision to allow unknown (not
invalid) messages.
This had allowed us to deploy stuff like compact blocks, feefilter, etc.
without breaking backward compatibility.
IMO, without a such flexibility, the deployment complexity would be
irresponsible high without really solving the DOS problem.
>
>> Why would your implementation how you threat unknown messages be
> different for messages specified in BIP151?
>
> Because it properly validates the protocol.
For feefilter or compact block or sendheaders?
You can't link a (unimplemented) specification (improvement process) to
a protocol version before deployment. Or can you?
Once it has been widely deployed, we should set a protocol minversion
for BIP151, right.
</jonas>
--TDr5xUoebJE8C3VLxT8NxMSHNkHv61GcC--
--dNnVSQvgskeC9aXb0wsEX5aG6L0aUnxwQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEMu5cTD+hXMrbRqvlKdS8tkFvU+wFAlihlPoACgkQKdS8tkFv
U+ykfA/9FIfkaoqjvjerNkUO3q9pjAU9iBpdpYkjdsYy0v/AJipVSUfHOrSEUFaM
mLxPaojG2Ib7WCFIFSk71lI5nAejW4WyNqZ2HMD8XoK++Rpl815cKHKu5y/Ih3D+
J1rIxMdWMaaW+QBu58sVUYpRNcDYqzxCbH6ZLLdNeuPkedr2UppregpWCKeNsUhw
2NBYvohbNLe6CpysbRP4fJvb18SxCqBxwNnBQeL7ioGMnkLRZknvBzUmPQYdTwMo
ZYx+iu3k/i6RB5l9k7ZrjWLRqI9ionPa2lvIZYgNGcA9q+ysaahVNrHlX04532j7
TiRxcPRzOH8X8qTpslNBvIMaruVovDbgym8kbp5qO4BZ71p4r5RlnalvDwtz+InI
IJX2YFB6ghMWXOP4EjqMlihhbGuy9sAcuQvJALWN6G5DV5FKipuCgMQ0DLhs9QQR
JHnON6fT4royw7ODFVOFyfmXWW2EFv47XaGOaSVVugFWEDUb7KH/NFUE7Um8SgyJ
sDFlyZO70ML8EGXs0obGUn4FXTefieM3ZY+MvrEBRsTJdvH+2UOrZ6sw5qgv+HsW
getzw9T5H0keFv4EALdrh2s8VtdfkchiwTmAt/rdP9t90zOSJ8NLOMYHfCYu175N
Uh/iEeVyvl6ZiAogJnquUUULfNvbZZONmggz/AaNHYeD2QKDNUg=
=15N5
-----END PGP SIGNATURE-----
--dNnVSQvgskeC9aXb0wsEX5aG6L0aUnxwQ--
|
