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 7790E8FC for ; 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 ; Fri, 21 Aug 2015 05:48:26 +0000 (UTC) Received: by wicne3 with SMTP id ne3so10163308wic.1 for ; 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: From: Jeff Garzik To: Matt Corallo 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 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: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 , Peter Todd > 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
If this is widely deployed + enabled, what is the impact t= o current wallets in use?

On Fri, Aug 21, 2015 at 12:46 AM, Matt Corallo= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
Peter: Since I st= ole 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@peterto= dd.org>
Type: Standards Track (draft)
Created: 20-08-2015

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. 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
=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.
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The following protocol bit is added:

=C2=A0 =C2=A0 NODE_BLOOM =3D (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&qu= ot;,
"filteradd", or "filterclear" message from a peer the n= ode 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
=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. 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<= br> 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
=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/6579


Copyright
=3D=3D=3D=3D=3D=3D=3D=3D=3D

This document is placed in the public domain.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e0141aa1ae111ed051dcbd093--