Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.113 as permitted sender)
	client-ip=62.13.149.113; envelope-from=pete@petertodd.org;
	helo=outmail149113.authsmtp.com; 
Date: Fri, 6 Jun 2014 13:45:45 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140606174545.GB29195@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>
	<CAAS2fgT3CfJ9Lf2H2BYVfUeJoF0RBi+EMmAghj5G2vJPtahmjg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA"
Content-Disposition: inline
In-Reply-To: <CAAS2fgT3CfJ9Lf2H2BYVfUeJoF0RBi+EMmAghj5G2vJPtahmjg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom bait
Precedence: list


--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 06, 2014 at 10:10:51AM -0700, Gregory Maxwell wrote:
> 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.
>=20
> 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.

Because I was designing a system under the assumption that you were
highly likely to connect to an attacker at some point, and the trade-off
available with the available math was to either give very detailed info
to that attacker, or give away some probabalistic info to everyone.

> > I explained all this in detail in my original blockchain data privacy w=
riteup months ago.
>=20
> 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.

Quite likely - I think most of this disagreement stems from the fact
that we have different starting assumptions. In particular my assumption
that you are likely to end up connecting to an attacker logging data,
and my desire to have a standard that can be implemented with existing
cryptographic primatives. Remember that I'm spending a lot of time
working with wallet authors; they have approximately zero interest in
standards that require crypto any more fancy than HD wallets do.

> 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=
 in
> 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.

Scanning performance is different from bandwidth performance. Prefix
brute-forcing was designed to address the latter concern for cases where
you are bandwidth limited and don't have a trusted peer to do the
scanning for you.

--=20
'peter'[:-1]@petertodd.org
00000000000000001c5e0fca7bd6d96211a37543c1d0cc2f594c15423ee3cdd8

--neYutvxvOLaeuPCA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTkf5FXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxOWU5YTIwNDdiZTNmOTYwOGQ4ZWZhNTVlYTAzZjdmMzc5
MTFlMDVmYTNlMTgzOGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsUjQf+ILSV0jvyXulBefvuz4eivTOD
2K4Jc6Tbc7bAWBFgT8JgiT3G1lnPVoBke31i38MxM95jY92hJNn/JJ1cUt7lWr1T
g/MG/Lsi63uXJ1h/JJx9gPxmmhnulv+w+KeudjVbbtxZ3RCFr1AKR0r/n6SciQdy
UWw6AmyPXiu2rdxC/lEIX6+3oneH26ITJlZSS0RB/nKZFjFt3JgCrYSJ8byLrP5F
bchMCt1gOzOUakPYh9vblxJ9P9KpOnYU+no9q1M/+PKcjW64z3O0CBetgp0dI78R
qqhPrvCUOCmhzuTSseB1qfWDJt6y27RCscZwlhyjDjFWny6oA7rAgnEF5OI/qw==
=UgCA
-----END PGP SIGNATURE-----

--neYutvxvOLaeuPCA--