From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <jgarzik@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7790E8FC for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 21 Aug 2015 05:48:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43BA4AB for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 21 Aug 2015 05:48:26 +0000 (UTC) Received: by wicne3 with SMTP id ne3so10163308wic.1 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Aug 2015 22:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QeLSw8LkLx+0mxc66T/ZSpd+qWGgRypZjZ6tSgS7PGQ=; b=UzZQn6yvcYkBiGpLt2ZtoQitn9Q1QWmio0w5POLCUCm3SWOq3ZMnt0VYvZo5yv6eQh QUf7Oo4icmsNdxQuPWwOrsjZk/NcFqo+G4vDvrg6fbPXa8NlA+J5Vp/1TK5S6cybP2N5 c70PCOa3af2z+DV7xePdGSQxP1sPgAANfjjeMZGVfyvUsf0QW6xJ5prEOf6ctBvky2PL KrYKcQQzruv2yTV0YggNmw/Ba4m0TWs+ANxzK0Zv6u5nLVPaFoeDYF+bzUB3C0lO2ab4 IunySRReiREgAjAgPtJi9jDT2Du101Bl0OWeGY5/2Q0Cm8K0DP4fHOVfiUHIgms/KrlC oVpg== MIME-Version: 1.0 X-Received: by 10.194.238.39 with SMTP id vh7mr11954211wjc.109.1440136103529; Thu, 20 Aug 2015 22:48:23 -0700 (PDT) Received: by 10.28.52.84 with HTTP; Thu, 20 Aug 2015 22:48:23 -0700 (PDT) In-Reply-To: <55D6AD19.10305@mattcorallo.com> References: <55D6AD19.10305@mattcorallo.com> Date: Fri, 21 Aug 2015 01:48:23 -0400 Message-ID: <CADm_WcZJEe4fz4dLYKeOzC0CWbM=-o92BvEF0qiGvNwyMjrEiA@mail.gmail.com> From: Jeff Garzik <jgarzik@gmail.com> To: Matt Corallo <lf-lists@mattcorallo.com> Content-Type: multipart/alternative; boundary=089e0141aa1ae111ed051dcbd093 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 development mailing list <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:48:27 -0000 --089e0141aa1ae111ed051dcbd093 Content-Type: text/plain; charset=UTF-8 If this is widely deployed + enabled, what is the impact to current wallets in use? On Fri, Aug 21, 2015 at 12:46 AM, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Peter: Since I stole most of this text from your old BIP, should I leave > you as an author? > > 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 > > Abstract > ======== > > 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. > > > Motivation > ========== > > 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. > > > Specification > ============= > > The following protocol bit is added: > > NODE_BLOOM = (1 << 2) > > 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. > > 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 > have). > > 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. > > 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. > > > Design rational > =============== > > A service bit was chosen as applying a bloom filter is a service. > > 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. > > > Reference Implementation > ======================== > > https://github.com/bitcoin/bitcoin/pull/6579 > > > Copyright > ========= > > This document is placed in the public domain. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --089e0141aa1ae111ed051dcbd093 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">If this is widely deployed + enabled, what is the impact t= o current wallets in use?<div><br></div></div><div class=3D"gmail_extra"><b= r><div class=3D"gmail_quote">On Fri, Aug 21, 2015 at 12:46 AM, Matt Corallo= via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.= linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or= g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Peter: Since I st= ole most of this text from your old BIP, should I leave<br> you as an author?<br> <br> BIP: ?<br> Title: NODE_BLOOM service bit<br> Author: Matt Corallo <<a href=3D"mailto:bip@bluematt.me">bip@bluematt.me= </a>>, Peter Todd <<a href=3D"mailto:pete@petertodd.org">pete@peterto= dd.org</a>><br> Type: Standards Track (draft)<br> Created: 20-08-2015<br> <br> Abstract<br> =3D=3D=3D=3D=3D=3D=3D=3D<br> <br> This BIP extends BIP 37, Connection Bloom filtering, by defining a<br> service bit to allow peers to advertise that they support bloom filters<br> explicitly. It also bumps the protocol version to allow peers to<br> identify old nodes which allow bloom filtering of the connection despite<br= > lacking the new service bit.<br> <br> <br> Motivation<br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> <br> BIP 37 did not specify a service bit for the bloom filter service, thus<br> implicitly assuming that all nodes that serve peers data support it.<br> However, the connection filtering algorithm proposed in BIP 37, and<br> implemented in several clients today, has been shown to provide little<br> to no privacy, as well as being a large DoS risk on some nodes. Thus,<br> allowing node operators to disable connection bloom filtering is a<br> much-needed feature.<br> <br> <br> Specification<br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> <br> The following protocol bit is added:<br> <br> =C2=A0 =C2=A0 NODE_BLOOM =3D (1 << 2)<br> <br> Nodes which support bloom filters should set that protocol bit.<br> Otherwise it should remain unset. In addition the protocol version is<br> increased from 70002 to 70011 in the reference implementation. It is<br> often the case that nodes which have a protocol version smaller than<br> 70011, but larger than 70000 support bloom filtered connections without<br> the NODE_BLOOM bit set, however clients which require bloom filtered<br> connections should avoid making this assumption.<br> <br> NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise<br> NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode<br> which, nonetheless, provide filtered access to the data which they do have)= .<br> <br> If a node does not support bloom filters but receives a "filterload&qu= ot;,<br> "filteradd", or "filterclear" message from a peer the n= ode should<br> disconnect that peer immediately. For backwards compatibility, in<br> initial implementations, nodes may choose to only disconnect nodes which<br= > have the new protocol version set and attempt to send a filter command.<br> <br> While outside the scope of this BIP it is suggested that DNS seeds and<br> other peer discovery mechanisms support the ability to specify the<br> services required; current implementations simply check only that<br> NODE_NETWORK is set.<br> <br> <br> Design rational<br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> <br> A service bit was chosen as applying a bloom filter is a service.<br> <br> The increase in protocol version is for backwards compatibility. In<br> initial implementations, old nodes which are not yet aware of NODE_BLOOM<br= > and use a protocol version < 70011 may still send filter* messages to a<= br> node without NODE_BLOOM. This feature may be removed after there are<br> sufficient NODE_BLOOM nodes available and SPV clients have upgraded,<br> allowing node operators to fully close the bloom-related DoS vectors.<br> <br> <br> Reference Implementation<br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br= > <br> <a href=3D"https://github.com/bitcoin/bitcoin/pull/6579" rel=3D"noreferrer"= target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6579</a><br> <br> <br> Copyright<br> =3D=3D=3D=3D=3D=3D=3D=3D=3D<br> <br> This document is placed in the public domain.<br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div><br></div> --089e0141aa1ae111ed051dcbd093--