Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.179 as permitted sender)
	client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f179.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <20140610170846.GB21293@savin>
References: <CAJHLa0OJffXU_LkmVhCJ80mphc5zEPuDZzuSKvpLkrNUWU7Y1w@mail.gmail.com>
	<CANEZrP33n+UBE+0Zb_mh=+qjJA+C+Nny9quC5B0HpuLC1XygMA@mail.gmail.com>
	<20140610170846.GB21293@savin>
Date: Wed, 11 Jun 2014 10:57:29 +0200
Message-ID: <CANEZrP14gOCvWyDqJPEC=XRYMYKEXNi2AhN=FPw=jH+vR_vG-w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c2f644610b5c04fb8ba2ed
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom bait
Precedence: list

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

>
> Is this any different from my bloom filter IO attack code? Nope.
>

It's obviously different; a thin client trying to obtain more privacy is
not attempting to deny service to anyone. You can't simply state that a
feature which uses resources for a legitimate reason is a DoS attack,
that's a spurious definition that would reclassify innocuous things like
web browser prefetching as DoS attacks too.

With respect to the work you're proposing, trying to retroactively make
Bloom filtering an optional part of the protocol is just wasting people's
time at this point:

   - There is no evidence there's an actual problem today.
   - There is no evidence there will be a problem any time soon, given the
   meagre levels of traffic growth we have.
   - It involves a complicated rollout strategy that would create work for
   many people.
   - Gavin, Wladimir and myself have all concluded it's not worth the cost.
   - The only justification you have provided is that two node
   implementations hardly anyone uses can't be bothered to implement Bloom
   filtering, but want to advertise support in their ver message anyway. They
   can simply lower the number they advertise in their ver message.

That said, if you want to implement better support for archival nodes then
that'd be great. The way to do it would be either to implement block ranges
in the addr announcements as has been discussed many times before, or
perhaps introduce a new protocol optimised for serving the chain. Nodes
that are CPU limited won't want to take part in the rest of the P2P
protocol anyway, it's not just Bloom filtering that uses CPU time but also
block and tx relay.

But until you have done these things, please stop attempting to reclassify
any feature you can imagine a more efficient version of as an "attack".
It's just silly.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div class=3D"">Is this any different from my bloom filter IO attack code? =
Nope.</div></blockquote><div><br></div><div>It&#39;s obviously different; a=
 thin client trying to obtain more privacy is not attempting to deny servic=
e to anyone. You can&#39;t simply state that a feature which uses resources=
 for a legitimate reason is a DoS attack, that&#39;s a spurious definition =
that would reclassify innocuous things like web browser prefetching as DoS =
attacks too.</div>
<div><br></div><div>With respect to the work you&#39;re proposing, trying t=
o retroactively make Bloom filtering an optional part of the protocol is ju=
st wasting people&#39;s time at this point:</div><div><ul><li>There is no e=
vidence there&#39;s an actual problem today.</li>
<li>There is no evidence there will be a problem any time soon, given the m=
eagre levels of traffic growth we have.</li><li>It involves a complicated r=
ollout strategy that would create work for many people.</li><li>Gavin, Wlad=
imir and myself have all concluded it&#39;s not worth the cost.</li>
<li>The only justification you have provided is that two node implementatio=
ns hardly anyone uses can&#39;t be bothered to implement Bloom filtering, b=
ut want to advertise support in their ver message anyway. They can simply l=
ower the number they advertise in their ver message.</li>
</ul><div><div>That said, if you want to implement better support for archi=
val nodes then that&#39;d be great. The way to do it would be either to imp=
lement block ranges in the addr announcements as has been discussed many ti=
mes before, or perhaps introduce a new protocol optimised for serving the c=
hain. Nodes that are CPU limited won&#39;t want to take part in the rest of=
 the P2P protocol anyway, it&#39;s not just Bloom filtering that uses CPU t=
ime but also block and tx relay.=C2=A0</div>
<div><br></div><div>But until you have done these things, please stop attem=
pting to reclassify any feature you can imagine a more efficient version of=
 as an &quot;attack&quot;. It&#39;s just silly.=C2=A0</div></div></div></di=
v>
</div></div>

--001a11c2f644610b5c04fb8ba2ed--