summaryrefslogtreecommitdiff
path: root/b2/17a7b17a7a43bf07e69de83bcb637ffb32cf7f
blob: e5d991f24b7250dce27b64b34c3fd4155521b598 (plain)
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
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 E2FD24A4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 13 Feb 2017 09:36:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com [74.125.83.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E28316A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 13 Feb 2017 09:36:18 +0000 (UTC)
Received: by mail-pg0-f45.google.com with SMTP id 204so31355560pge.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 13 Feb 2017 01:36:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=subject:to:references:cc:from:message-id:date:user-agent
	:mime-version:in-reply-to;
	bh=M00owtaCIhDBqZGpnGIQ4oyYFhLOmmNjk+huvo4+5vI=;
	b=vF9du9MkAblLDWnRRCP8GAh+KVEuqzPqDE9pbcMUChdeXpItnjU7mrNmZaZEoJoqH9
	RSMTT4o1aXiWAbQlZl+6PAPRAnvFr8Outa/SOYDxSzIJfBZCP6KcKl6TciC9h3DrmGh4
	VOpiKWsvurA45X2uU20svaldfLr20tLJMQ7HldUsIiYBlBOSWe1K5Fv1FyaF6AjsmKUF
	TrE61wCYxoTyAsgjkk4udx23gjiUn1XC0eJFCCpicljG5ua+NS6HfnGevdWAuaDDcGzb
	gJnh5H41MUkCo3MFhNeccU7SsXNNBmTW83J7Hfa4vtJk/g7PjNxRf/eh6duFTNF/9Z/p
	DtAw==
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:cc:from:message-id:date
	:user-agent:mime-version:in-reply-to;
	bh=M00owtaCIhDBqZGpnGIQ4oyYFhLOmmNjk+huvo4+5vI=;
	b=HuEdKNOfHWNEaKpc+jpehyDmOQwpv5bFO8iy0lr6Q1LJyhR4Wx5I05falxQ/AAWDlO
	VuTXumdM5JGIZt1cEuK0/p1Spy8yXjRYa9kKf5AP5T/1cZFBlG4GWkevTT8CSKPVHoEp
	NIAYCsDauRlfyB0bGFvYVgH1SSQGEVaCApHy/o/BJTrgKekJRm1Gf41I1JBxFFNF6QG+
	hw375ozDi/iylG7JbmMxH3Xrku9T7uJ5lXzQoAnhLtaLShB9l8zUQTdI+3RO/iVUdd3R
	4aBUdqP3LHIUvLWWVaPSPOwKpYYGHIaY/1so2p75tj1gW+UIpwkBdjEgXNuX1Zl7cjXB
	iSUA==
X-Gm-Message-State: AMke39nv3tUnnVfS9P/hpoyd2rQp6eZiW1ViLA/O3mYV7OZQ3UAsvl1LpannFQaBP8sZcg==
X-Received: by 10.98.33.66 with SMTP id h63mr25189845pfh.142.1486978577925;
	Mon, 13 Feb 2017 01:36:17 -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
	2sm13345611pfv.100.2017.02.13.01.36.17
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 13 Feb 2017 01:36:17 -0800 (PST)
To: Pieter Wuille <pieter.wuille@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
	<CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
Date: Mon, 13 Feb 2017 01:36:21 -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: <CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="x4txsL7JAQCvdGQiWtCd0IoM6VAcOWUFh"
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 09:50:00 +0000
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 09:36:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--x4txsL7JAQCvdGQiWtCd0IoM6VAcOWUFh
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/13/2017 12:47 AM, Pieter Wuille wrote:
> On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org wrote:
>=20
>     The BIP151 proposal states:
>=20
>     > This proposal is backward compatible. Non-supporting peers will i=
gnore
>     the encinit messages.
>=20
>     This statement is incorrect. Sending content that existing nodes do=
 not
>     expect is clearly an incompatibility. An implementation that ignore=
s
>     invalid content leaves itself wide open to DOS attacks. The version=

>     handshake must be complete before the protocol level can be determi=
ned.
>     While it may be desirable for this change to precede the version
>     handshake it cannot be described as backward compatible.
>=20
> The worst possible effect of ignoring unknown messages is a waste of
> downstream bandwidth. The same is already possible by being sent addr
> messages.
>=20
> Using the protocol level requires a strict linear progression of
> (allowed) network protocol features, which I expect to become harder an=
d
> harder to maintain.
>=20
> 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


--x4txsL7JAQCvdGQiWtCd0IoM6VAcOWUFh
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)

iQEcBAEBAgAGBQJYoX4WAAoJEDzYwH8LXOFO9NIH/is/59itfMzO+vPh5zVZd7a4
V4jagor7z5K++gZVsGkp9AvHVrF7xx0qP0StrBp61F25/tFU/MbU0O7190XhsfyA
lYni0dU1Qng6l2/biIn4myEhDPiiZN3Y0uHgR9Nn+AbajODkQ+u7ONtZ1evcW6v3
65EMvRDvPX5pY03rINoenwNaGKJb+AlkMeQPMfxC5OhUhQA54s7WtRiHpUvArJox
GTLcVarYbiucX4SweTKIVwg2d/FiIW9yTJ6TMLP8bpDFM7ncGV4Yuj0b4revwAd1
nKS8+b1Nn6Kw9ejm1uDdoaTfpSLpLlwF3JW5cRHiTaiu1tXTATlFkU0rSEiTwwg=
=GyH6
-----END PGP SIGNATURE-----

--x4txsL7JAQCvdGQiWtCd0IoM6VAcOWUFh--