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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CC6F172A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 08:47:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3431488
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 08:47:40 +0000 (UTC)
Received: by mail-wm0-f68.google.com with SMTP id r18so18086819wmd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 00:47:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=nIQIguwARaPwMj/oezltyRypJTKAhsAyUsN7hpsiY74=;
b=dusZ+SSLdqTJdTy9j1rXxCQVHqniW5wKbVf9NyzXQRqf3WgtbtGkLe/OY04G5Vx/Oz
EJb/fJSr2tudDGRlpKRUk81CerRaJX9zmTJ7dRT8sC2m5Pl6njEoD812gkKpDkQuGTP4
CkSntCDlIt5rWRdfBKCblvymnjnwC+TlU+8S88Uqd90zKc+eDnpDSkVi4uZo3erMf/JG
6TNz8e+v+eN/w1r4KdOIYTOynSGr53tQAOhFF2WiSZh74pxLUxeHQtgmynMChmknP7JO
VU6j0/z/0FbbMIjaDRrp4im4X9+6mZRpic5zqYuVfrcdt/zaXaLQKRdv3jr9IKaIuI8D
wxGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=nIQIguwARaPwMj/oezltyRypJTKAhsAyUsN7hpsiY74=;
b=Y4WLGQnTF1rGEJvSoPnuPz8ZB3M7/iveSTfqVGto1yv1yI047gNUHM0X4Poc4sr56S
zmnXE78ki5Gs8a++6rURh67EuvORV6D2i/kZbUYVSS71lo9O0QMgMcdjo8GOYhuHt3vN
BV9O7R4Y0rVSKgMSC5RgzdK48oMUwIXhKyN2UyVrHJI9tradyViiuWxNgLSwA/LpiY9n
aqFEBeTv6ZZSOwQZ+lsvAbjsXOY0/r5qNa/tlrf+Grp+PZqmUrAuxDVu8nSWBBx9ab23
Ru3ht6BWTwFWhJYppRYnAadwuzD6VEsHt2XVm0tUdZwyCI+ZlXxYMUFxAA3gxR1VbmyT
Iraw==
X-Gm-Message-State: AMke39kRn/lUVqwX+wQfsxk1clUxhY9LrgFG13fQbXUfWg7AIZ8EmBFkbdVzXPaL4RIwh6opfED3bkKjMGnKoQ==
X-Received: by 10.28.180.132 with SMTP id d126mr37928800wmf.123.1486975658693;
Mon, 13 Feb 2017 00:47:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.142.68 with HTTP; Mon, 13 Feb 2017 00:47:38 -0800 (PST)
Received: by 10.80.142.68 with HTTP; Mon, 13 Feb 2017 00:47:38 -0800 (PST)
In-Reply-To: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Mon, 13 Feb 2017 00:47:38 -0800
Message-ID: <CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=001a114b2e44ed1f950548657f1f
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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
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 08:47:40 -0000
--001a114b2e44ed1f950548657f1f
Content-Type: text/plain; charset=UTF-8
On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev" <
bitcoin-dev@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.
--
Pieter
--001a114b2e44ed1f950548657f1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev" &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>> wrote:<br type=3D"attribution"><blockquote c=
lass=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">The BIP151 proposal states:<br>
<br>
> This proposal is backward compatible. Non-supporting peers will ignore=
<br>
the encinit messages.<br>
<br>
This statement is incorrect. Sending content that existing nodes do not<br>
expect is clearly an incompatibility. An implementation that ignores<br>
invalid content leaves itself wide open to DOS attacks. The version<br>
handshake must be complete before the protocol level can be determined.<br>
While it may be desirable for this change to precede the version<br>
handshake it cannot be described as backward compatible.</blockquote></div>=
</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">The worst possibl=
e effect of ignoring unknown messages is a waste of downstream bandwidth. T=
he same is already possible by being sent addr messages.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Using the protocol level requires a strict=
linear progression of (allowed) network protocol features, which I expect =
to become harder and harder to maintain.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">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.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">--=C2=A0</div><div dir=
=3D"auto">Pieter</div><div dir=3D"auto"><br></div><div dir=3D"auto"></div><=
div dir=3D"auto"><div class=3D"gmail_extra"><br></div></div></div>
--001a114b2e44ed1f950548657f1f--
|
