path: root/91/a886eddb786ce4430aef5dc9e44f592bfa298c

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1VBB1S-0008MK-Ny
	for bitcoin-development@lists.sourceforge.net;
	Sun, 18 Aug 2013 22:00:30 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.54 as permitted sender)
	client-ip=209.85.219.54; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f54.google.com; 
Received: from mail-oa0-f54.google.com ([209.85.219.54])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VBB1R-0007HE-2o
	for bitcoin-development@lists.sourceforge.net;
	Sun, 18 Aug 2013 22:00:30 +0000
Received: by mail-oa0-f54.google.com with SMTP id o6so4698832oag.13
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 18 Aug 2013 15:00:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.119.229 with SMTP id kx5mr9711070obb.23.1376863223597;
	Sun, 18 Aug 2013 15:00:23 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.80.165 with HTTP; Sun, 18 Aug 2013 15:00:23 -0700 (PDT)
In-Reply-To: <20130818025932.GA372@savin>
References: <20130818025932.GA372@savin>
Date: Mon, 19 Aug 2013 00:00:23 +0200
X-Google-Sender-Auth: 0Zt327XpHgCv3YB2JGkk58fE0UQ
Message-ID: <CANEZrP2jONtRJ6oF1YqKJB9nm1HcMkfz_yzeNshEWqD-5fdNiA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c2e352591e8404e43ff393
X-Spam-Score: -0.5 (/)
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
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VBB1R-0007HE-2o
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 22:00:31 -0000

--001a11c2e352591e8404e43ff393
Content-Type: text/plain; charset=UTF-8

The original Bloom filtering spec did not make this feature optional for
the same reason gzip isn't an optional part of the PNG specification. I see
no reason to revisit that. It's definitely not the case that making every
possible feature optional is smart design, often it's the opposite.

If in future there are nodes that for some reason can't technically support
this feature, then there'd be a stronger rationale for something like this.
However no such nodes exist, nor are they likely to in future given that
it's a simple feature to implement.

For these reason I oppose this BIP.


On Sun, Aug 18, 2013 at 4:59 AM, Peter Todd <pete@petertodd.org> wrote:

> 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
> ========
>
> 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
> ==========
>
> 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
> as 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
> =============
>
> The following protocol bit is added:
>
>     NODE_BLOOM = (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
> 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. 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
> can
> easily connect to another peer.
>
> Supporting NODE_BLOOM but not NODE_NETWORK allows for situations where a
> node
> may have data that its peers may be interested in, but is not a full node
> and
> 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
> requested.
> 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
> made
> prohibitively expensive by the work required to create a valid block
> header.
>
>
> Reference Implementation
> ========================
>
> https://github.com/bitcoin/bitcoin/pull/2900
>
>
> Copyright
> =========
>
> This document is placed in the public domain.
>
> --
> 'peter'[:-1]@petertodd.org
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a11c2e352591e8404e43ff393
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The original Bloom filtering spec did not make this featur=
e optional for the same reason gzip isn&#39;t an optional part of the PNG s=
pecification. I see no reason to revisit that. It&#39;s definitely not the =
case that making every possible feature optional is smart design, often it&=
#39;s the opposite.<div>
<br></div><div>If in future there are nodes that for some reason can&#39;t =
technically support this feature, then there&#39;d be a stronger rationale =
for something like this. However no such nodes exist, nor are they likely t=
o in future given that it&#39;s a simple feature to implement.</div>
<div><br></div><div>For these reason I oppose this BIP.</div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Aug 18, 2013 =
at 4:59 AM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"mailto:pete@peterto=
dd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">My draft is as follows.<br>
<br>
Gregory Maxwell: Can you assign a BIP # for this? The next number, 38,<br>
is on the wiki as &quot;Passphrase-protected private key&quot; by Mike Cald=
well,<br>
although it isn&#39;t in the list so I don&#39;t know if that is official o=
r<br>
not.<br>
<br>
<br>
<br>
BIP: ?<br>
Title: NODE_BLOOM service bit<br>
Author: Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd=
.org</a>&gt;<br>
Type: Standards Track (draft)<br>
Created: 17-08-2013<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 service =
bit<br>
to allow peers to advertise that they support bloom filters explicitly.<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. There =
are<br>
however cases where a node may want to provide data, such as mempool<br>
transactions and blocks, but do not want to or have not implemented bloom<b=
r>
filtering. Additionally it is good practice for nodes to be given options a=
s to<br>
the granularity of the services they are providing the public - a full-node=
<br>
operator may be able to donate only a small amount of bandwidth and may wan=
t<br>
those efforts to be used by other full-node operators.<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; 1)<br>
<br>
In addition the protocol version is increased from 70001 to 70002 in the<br=
>
reference implementation. Nodes that support bloom filters should set that<=
br>
protocol bit. Otherwise it should remain unset.<br>
<br>
NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise<br>
NODE_BLOOM but not NODE_NETWORK.<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 disconnect<br>
that peer immediately.<br>
<br>
While outside the scope of this BIP it is suggested that DNS seeds and othe=
r<br>
peer discovery mechanisms support the ability to specify the services requi=
red;<br>
current implementations simply check only that 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. Nodes that=
<br>
require the bloom filter service can set NODE_BLOOM for peers advertising a=
<br>
protocol version &lt; 70002, allowing the rest of the implementation to be<=
br>
unchanged. Nodes with implementations that do not know of the NODE_BLOOM bi=
t<br>
will be disconnected immediately as though the connection failed for some<b=
r>
reason, and thus will not have incoming bandwidth wasted by that peer and c=
an<br>
easily connect to another peer.<br>
<br>
Supporting NODE_BLOOM but not NODE_NETWORK allows for situations where a no=
de<br>
may have data that its peers may be interested in, but is not a full node a=
nd<br>
thus does not have block data in general. For instance an SPV node that<br>
receives a full, unfiltered, block from a peer may want to let its SPV peer=
s<br>
know about the existence of that block and provide them that data if reques=
ted.<br>
Those peers in turn may only be interested in knowing about the block if it=
<br>
matches a specific bloom filter. Note how in this example DoS attacks are m=
ade<br>
prohibitively expensive by the work required to create a valid block header=
.<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/2900" target=3D"_blank">=
https://github.com/bitcoin/bitcoin/pull/2900</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>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It&#39;s a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with &lt;2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48897031&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&amp;iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>

Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--001a11c2e352591e8404e43ff393--