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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D0C2E8EF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 05:38:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148113.authsmtp.com (outmail148113.authsmtp.com
[62.13.148.113])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id E09EEE3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 05:38:35 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7L5cYuH006256;
Fri, 21 Aug 2015 06:38:34 +0100 (BST)
Received: from muck ([24.114.27.112]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7L5cKRJ099527
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 21 Aug 2015 06:38:29 +0100 (BST)
Date: Thu, 20 Aug 2015 22:38:19 -0700
From: Peter Todd <pete@petertodd.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <20150821053819.GA18176@muck>
References: <55D6AD19.10305@mattcorallo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1"
Content-Disposition: inline
In-Reply-To: <55D6AD19.10305@mattcorallo.com>
X-Server-Quench: dcb8e869-47c6-11e5-b398-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAMUGUATAgsB AmMbW1JeU1V7WmA7 aQ5PbARZfEhJQQRr
UldMSlVNFUssBmAE VWV8KBl7fgBEfzBx ZURkWD4PDxZyIE57
S1NQEj4AeGZhPWUC AkNRfx5UcAFPdx8U a1UrBXRDAzANdhg1
AQ4oPiwwOzoXDgN5 bzYnCXU1ZBRDJiQ7 XxcZEDlnN2w9LwAA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 24.114.27.112/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 21 Aug 2015 05:38:36 -0000
--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 21, 2015 at 04:46:17AM +0000, Matt Corallo wrote:
> Peter: Since I stole most of this text from your old BIP, should I leave
> you as an author?
That's fine by me.
> BIP: ?
> Title: NODE_BLOOM service bit
> Author: Matt Corallo <bip@bluematt.me>, Peter Todd <pete@petertodd.org>
> Type: Standards Track (draft)
> Created: 20-08-2015
>=20
> Abstract
> =3D=3D=3D=3D=3D=3D=3D=3D
>=20
> This BIP extends BIP 37, Connection Bloom filtering, by defining a
> service bit to allow peers to advertise that they support bloom filters
> explicitly. It also bumps the protocol version to allow peers to
> identify old nodes which allow bloom filtering of the connection despite
> lacking the new service bit.
>=20
>=20
> Motivation
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> BIP 37 did not specify a service bit for the bloom filter service, thus
> implicitly assuming that all nodes that serve peers data support it.
> However, the connection filtering algorithm proposed in BIP 37, and
> implemented in several clients today, has been shown to provide little
> to no privacy, as well as being a large DoS risk on some nodes. Thus,
> allowing node operators to disable connection bloom filtering is a
> much-needed feature.
I'd reference that paper on bloom filters re: the "little to no privacy"
issue. There's also a post in the bitcoinj mailing list somewhere IIRC
talking about the default settings, and how they don't provide any
privacy.
> Specification
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> The following protocol bit is added:
>=20
> NODE_BLOOM =3D (1 << 2)
>=20
> Nodes which support bloom filters should set that protocol bit.
> Otherwise it should remain unset. In addition the protocol version is
> increased from 70002 to 70011 in the reference implementation. It is
> often the case that nodes which have a protocol version smaller than
> 70011, but larger than 70000 support bloom filtered connections without
> the NODE_BLOOM bit set, however clients which require bloom filtered
> connections should avoid making this assumption.
>=20
> NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
> NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
> which, nonetheless, provide filtered access to the data which they do hav=
e).
>=20
> If a node does not support bloom filters but receives a "filterload",
> "filteradd", or "filterclear" message from a peer the node should
> disconnect that peer immediately. For backwards compatibility, in
> initial implementations, nodes may choose to only disconnect nodes which
> have the new protocol version set and attempt to send a filter command.
>=20
> While outside the scope of this BIP it is suggested that DNS seeds and
> other peer discovery mechanisms support the ability to specify the
> services required; current implementations simply check only that
> NODE_NETWORK is set.
Good to note Mike Hearn's Cartography seed protocol here.
> Design rational
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> A service bit was chosen as applying a bloom filter is a service.
>=20
> The increase in protocol version is for backwards compatibility. In
> initial implementations, old nodes which are not yet aware of NODE_BLOOM
> and use a protocol version < 70011 may still send filter* messages to a
> node without NODE_BLOOM. This feature may be removed after there are
> sufficient NODE_BLOOM nodes available and SPV clients have upgraded,
> allowing node operators to fully close the bloom-related DoS vectors.
Ah good! That solves the backwards compatibility quite nicely.
--=20
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
--n8g4imXOkfNTN/H1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJV1rlIXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi
ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxKqQf9Et4RwmBFkAkZvvA0qLVLkkaE
7saMRfbrTx0deHSkgiD838BGLqOC98zvg/oLbOvxvG/dJaqY0MADgYjYy6sijWLT
Wjodo+uPpPT9AYJD2Km9mgKNCWmQFKkE8WeTr9Tc9BVhTVSSCaagjm2+o9UPGG7I
mCaAkher/MtxDhu67WjnmkIiYhSLepcw7GXGn4Q06Nl6kIsFbwa+3R3dW/yr0q6T
izIHBqZr/Pu2ALi0rKwIraOt1yXY2PcZ3Za06GYUjWC7yBfY3SchqXTJYXEwJGc0
9DMq9GA2qhsKWDuaTBIE/i36UtdPlQCScJCO1hfb06PkIlteFtNHZ6ZSkgXB8g==
=BGsD
-----END PGP SIGNATURE-----
--n8g4imXOkfNTN/H1--
|
