Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.53 as permitted sender)
	client-ip=209.85.215.53; envelope-from=gmaxwell@gmail.com;
	helo=mail-la0-f53.google.com; 
MIME-Version: 1.0
In-Reply-To: <20140606170524.GA29195@savin>
References: <20140606081933.GA29458@savin>
	<20140606084852.GA30247@netbook.cypherspace.org>
	<20140606090441.GA19256@savin>
	<20140606104543.GA31085@netbook.cypherspace.org>
	<20140606164639.GB14891@savin>
	<CAAS2fgTKiPMPOazNTPL8+3Ov1xOj=H+yK3u+sd_pe=nyDSPgTw@mail.gmail.com>
	<20140606170524.GA29195@savin>
Date: Fri, 6 Jun 2014 10:10:51 -0700
Message-ID: <CAAS2fgT3CfJ9Lf2H2BYVfUeJoF0RBi+EMmAghj5G2vJPtahmjg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom bait
Precedence: list

On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd <pete@petertodd.org> wrote:
> Again, you *don't* have to use brute-force prefix selection. You can
> just as easily give your peer multiple prefixes, each of which
> corresponds at least one address in your wallet with some false positive
> rate. I explained all this in detail in my original blockchain data
> privacy writeup months ago.

I'm not trying to pick nits about all the options,  I just found it
surprising that you were saying that data published in a super public
manner is no different than something used between nodes.

> I explained all this in detail in my original blockchain data privacy wri=
teup months ago.

Communication is a two way street, Adam and I (and others) are
earnestly trying=E2=80=94 that we're not following your arguments may be a
suggestion that they need to be communicated somewhat differently.

I'm still failing to see the usefulness of having any prefix filtering
for DH-private outputs. It really complicates the security story=E2=80=94 i=
n
particular you don't know _now_ what activities will turn your prior
information leaks into compromising ones retrospectivelly, and doesn't
seem at very necessary for scanning performance.