From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D0C2E8EF for ; 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 ; 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 To: Matt Corallo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 , Peter Todd > 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--