path: root/a6/8646527a7524e2bfd0d5cf92f4b73920f9a211

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">&lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt;</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 &lt;<a href=3D"mailto:bip@bluematt.me">bip@bluematt.me=
</a>&gt;, Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@peterto=
dd.org</a>&gt;<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 &lt;&lt; 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 &quot;filterload&qu=
ot;,<br>
&quot;filteradd&quot;, or &quot;filterclear&quot; 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 &lt; 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--