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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VAtDW-0000Pr-Cv
for bitcoin-development@lists.sourceforge.net;
Sun, 18 Aug 2013 02:59:46 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.96 as permitted sender)
client-ip=62.13.148.96; envelope-from=pete@petertodd.org;
helo=outmail148096.authsmtp.net;
Received: from outmail148096.authsmtp.net ([62.13.148.96])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VAtDU-0002FC-Ur for bitcoin-development@lists.sourceforge.net;
Sun, 18 Aug 2013 02:59:46 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r7I2xaWc071765; Sun, 18 Aug 2013 03:59:36 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r7I2xWZi039325
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 18 Aug 2013 03:59:34 +0100 (BST)
Date: Sat, 17 Aug 2013 22:59:32 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130818025932.GA372@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 36c75f43-07b2-11e3-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwoUGUATAgsB AmUbW1deVVR7WmY7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqBmUD Tnl0CxlxfgZEfTBx bU9lXD5YWhd9cBB5
QVNUEj8EeGZhPWMC AkULch5UcAFPdx8U a1UrBXRDHxpzExUS OygUGngbHA03
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain 1.6 SUBJ_ALL_CAPS Subject is all capitals
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1VAtDU-0002FC-Ur
Subject: [Bitcoin-development] NODE_BLOOM BIP
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 18 Aug 2013 02:59:46 -0000
--Dxnq1zWXvFF0Q93v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
My draft is as follows.
Gregory Maxwell: Can you assign a BIP # for this? The next number, 38,
is on the wiki as "Passphrase-protected private key" by Mike Caldwell,
although it isn't in the list so I don't know if that is official or
not.
BIP: ?
Title: NODE_BLOOM service bit
Author: Peter Todd <pete@petertodd.org>
Type: Standards Track (draft)
Created: 17-08-2013
Abstract
=3D=3D=3D=3D=3D=3D=3D=3D
This BIP extends BIP 37, Connection Bloom filtering, by defining a service =
bit
to allow peers to advertise that they support bloom filters explicitly.
Motivation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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. There =
are
however cases where a node may want to provide data, such as mempool
transactions and blocks, but do not want to or have not implemented bloom
filtering. Additionally it is good practice for nodes to be given options a=
s to
the granularity of the services they are providing the public - a full-node
operator may be able to donate only a small amount of bandwidth and may want
those efforts to be used by other full-node operators.
Specification
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The following protocol bit is added:
NODE_BLOOM =3D (1 << 1)
In addition the protocol version is increased from 70001 to 70002 in the
reference implementation. Nodes that support bloom filters should set that
protocol bit. Otherwise it should remain unset.
NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
NODE_BLOOM but not NODE_NETWORK.
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.
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 requi=
red;
current implementations simply check only that NODE_NETWORK is set.
Design rational
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A service bit was chosen as applying a bloom filter is a service.
The increase in protocol version is for backwards compatibility. Nodes that
require the bloom filter service can set NODE_BLOOM for peers advertising a
protocol version < 70002, allowing the rest of the implementation to be
unchanged. Nodes with implementations that do not know of the NODE_BLOOM bit
will be disconnected immediately as though the connection failed for some
reason, and thus will not have incoming bandwidth wasted by that peer and c=
an
easily connect to another peer.
Supporting NODE_BLOOM but not NODE_NETWORK allows for situations where a no=
de
may have data that its peers may be interested in, but is not a full node a=
nd
thus does not have block data in general. For instance an SPV node that
receives a full, unfiltered, block from a peer may want to let its SPV peers
know about the existence of that block and provide them that data if reques=
ted.
Those peers in turn may only be interested in knowing about the block if it
matches a specific bloom filter. Note how in this example DoS attacks are m=
ade
prohibitively expensive by the work required to create a valid block header.
Reference Implementation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
https://github.com/bitcoin/bitcoin/pull/2900
Copyright
=3D=3D=3D=3D=3D=3D=3D=3D=3D
This document is placed in the public domain.
--=20
'peter'[:-1]@petertodd.org
--Dxnq1zWXvFF0Q93v
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSEDiTAAoJECSBQD2l8JH7p3oH/06xdaPql9I5UYs+VF5swRvj
CJU9X5/SwxbYU12knbzmsYza9TS6eXHx2KhJqNg5zRK/HyJqfhyo+8USQxDI5hJg
y2nb0VicKw0j9mMl0Tuby8uH10C+VXaANtxfT/Hs9IAO5i97+W/CcFMis1FZnyWw
POYbgyfJTr8t3mr9n+jGb72QLEYz1yK/7HwVhmrLZkeC2oG0Gsm8DKhvxukxjhht
PoKF6tsNlwbfHx+5EeWv1046mJi2qXZSoMvEjwNhTMM5m3/u8tAUaPYEHD777ER+
BeRagbsToGVAdQpCzvaUoc7EiAmTDXK64KgShu7jPg4J+UUUHgpVghYreoF+JXg=
=jqH2
-----END PGP SIGNATURE-----
--Dxnq1zWXvFF0Q93v--
|
