From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WsxGv-0007uA-J6 for bitcoin-development@lists.sourceforge.net; Fri, 06 Jun 2014 16:45:41 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.95 as permitted sender) client-ip=62.13.149.95; envelope-from=pete@petertodd.org; helo=outmail149095.authsmtp.com; Received: from outmail149095.authsmtp.com ([62.13.149.95]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WsxGt-0001hc-MM for bitcoin-development@lists.sourceforge.net; Fri, 06 Jun 2014 16:45:41 +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 s56GjR7L090256; Fri, 6 Jun 2014 17:45:27 +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 s56GjDvC005083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 17:45:16 +0100 (BST) Date: Fri, 6 Jun 2014 12:46:39 -0400 From: Peter Todd To: Adam Back Message-ID: <20140606164639.GB14891@savin> References: <20140606081933.GA29458@savin> <20140606084852.GA30247@netbook.cypherspace.org> <20140606090441.GA19256@savin> <20140606104543.GA31085@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: <20140606104543.GA31085@netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: f059feef-ed99-11e3-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgQUEkAaAgsB AmIbWlNeVFh7WGU7 bAxPbAVDY01GQQRq WVdMSlVNFUsrBBp2 XGpYIRlycgVOezBy Z05iVj4NXEFzIxMo FFMBQWQPeGZhPWMC 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 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information X-Headers-End: 1WsxGt-0001hc-MM Cc: bitcoin-development@lists.sourceforge.net 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 16:45:41 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 06, 2014 at 12:45:43PM +0200, Adam Back wrote: (changed subject line as this discussion has nothing to do with NODE_BLOOM) > As I recall prefix brute forcing was a bit twiddle saving, ie searching f= or > EDH key that has the users public prefix. That does not improve privacy > over an explicit prefix, it saves a byte or so at the expense of average = 128 > EDH exchanges to send and provides also some probably relatively ineffect= ive > plausible deniability by enabling the transaction to be indistinguishable > from some other (not very common) types of transaction. I think you should re-read my original proposal; there's a whole host of misunderstandings above, for instance I have no idea where you got the idea that it has anything to do with "saving a byte" came from, or where the number 128 came from. > >don't do that they have privacy equal or better than bloom filters, but > >with better scalability. >=20 > either its full node only where prefixes are not used, which is less > scalable than bloom; or prefixes are used explicitly or implicitly > (brute-force) and either way privacy is weakened by the extra correlation > hook provided by elimination from the network graph of payments with > mismatched prefixes. Again, you have a misunderstanding. Both bloom filters and prefix filters are just ways of giving a peer a probabalistic filter to match transactions against. Where they differ is that bloom filters has O(n) scaling, where n is the size of a block, and prefix filters have O(log n) scaling with slightly(1) higher k. Again, if you *don't* use brute forcing in conjunction with prefixes they have no different transactional graph privacy than bloom filters, but the better scalability lets you do things like split your queries across multiple peers that give you better protection against hostile nodes. Additionally prefix filters are compatible with future miner committed indexes to make the data authenticated. 1) see Amir's experience implementing prefix lookup in Obelisk > We need to consider the two types of privacy involved. Privacy from the > full node an SPV client is relying on to find its payments, vs privacy fr= om > analysis of the public transaction graph. Agreed > The latter is more damaging. Maybe! If adversaries are operating a significant fraction of the peers you are connecting to the current design of bloom filters + HD wallets results in situations where those adversaries have better transactional graph information than the alternative. > Better to design for privacy against future analysis of > public info, than > privacy by argument to select non-hostile nodes. Tor has changed recently > to account for the fact that chosing fresh random nodes is actually > worse. ie you have a probability of identity/address identification > per route/node, > and repeatedly selecting routes/nodes just cumulatively increases the cha= nce > you'll be identified. Better to pick a random node, identify it and stick > to it and hope you chose well. That's basically what Electrum and Obelisk already do - by default you connect to a relatively small set of blockchain data servers operated by well known people and use the same server repeatedly. Applying that to the P2P network however is tricky as there is a huge amount of churn in the nodes: #bitcoin-dev/14/06/14-06-06.log:11:18 < hearn> bitcoinj can't use [service bits] as it relies on DNS seeds and that is unlikely to change any time soon due to the general churn rate in the network making it hard to bootstrap quickly using just remembered sets of IPs. > Maybe other simpler, but yes there was the proof of concept that the math > exists in the form of the weil pairing. >=20 > https://bitcointalk.org/index.php?topic=3D431756.new I know, where can I find running code? Remember that a bug can easily lose thousands of dollars worth of Bitcoins. --=20 'peter'[:-1]@petertodd.org 00000000000000001d2af1653c415b7801ce4c9b18ac7e87bef597e652b203e6 --l76fUT7nc3MelDdI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTkfBrXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxNzhhZDVlNmY3YjM1MzVjNjEwNmI3YzZmMGJkZWI4MzFk YmQ4OWM2NDJiNmYyNzEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuJywf/Rj4CXObu9DlW4CvmhSsaa9jr Q8wcaI2VK7zSDoZFn5XsmyL4rXRov8y9s/VtPrja98aSErxLY8BGjiJVM5fh2kbS XZ02Hi8VxwKevNexVQW3XzKM1wj7vbm4JXn+cHkfj+NDKzR+QcZqgx95LB3XvRK4 fSnkWakzDrpvrR5PC/XGOiAYhpg1HWXYAvaflmeiO33Y/82Bj3yrjxq14RbkHjo/ 262LAZJ0SHD7d3S0B/53Jg9qHM79HkJEmIu8q/qAOdczv6VDhYnWQRuYBPoNip2c j/bFC8qI4QfqqFuZpadpHjNLivGIB1vw/szCpBwds6E5Janm2LMdCROezaj00w== =wJw+ -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI--