From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WsyC3-00007g-Ca for bitcoin-development@lists.sourceforge.net; Fri, 06 Jun 2014 17:44:43 +0000 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; Received: from outmail149113.authsmtp.com ([62.13.149.113]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WsyC2-0005zj-2s for bitcoin-development@lists.sourceforge.net; Fri, 06 Jun 2014 17:44:43 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s56HiVZU069151; Fri, 6 Jun 2014 18:44:31 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s56HiJJw050511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 18:44:21 +0100 (BST) Date: Fri, 6 Jun 2014 13:45:45 -0400 From: Peter Todd To: Gregory Maxwell 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> <20140606170524.GA29195@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 316e2647-eda2-11e3-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgQUEkAaAgsB AmIbWlxeVFl7W2E7 bAxPbAVDY01GQQRq WVdMSlVNFUsrBBp5 X2RkFRl3dwBHeTBx YkJgVj5YXUIvd0B5 RVMBQTwEeGZhPWMC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4hGjk7 QlgIFDQzdQAA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1WsyC2-0005zj-2s Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Bloom bait X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 17:44:43 -0000 --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 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--