From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W1Z3R-00069U-Gh for bitcoin-development@lists.sourceforge.net; Fri, 10 Jan 2014 10:11:05 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W1Z3Q-0000xg-7R for bitcoin-development@lists.sourceforge.net; Fri, 10 Jan 2014 10:11:05 +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 s0AAAwU1041625; Fri, 10 Jan 2014 10:10:58 GMT 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 s0AAAqMm060749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 10 Jan 2014 10:10:54 GMT Date: Fri, 10 Jan 2014 05:10:51 -0500 From: Peter Todd To: Jeremy Spilman Message-ID: <20140110101051.GA25749@savin> References: <20140106025312.GC2356@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 7e1aecb0-79df-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwIUElQaAgsB AmIbWlReUV17XGY7 bAxPbAVDY01GQQRq WVdMSlVNFUsrAW1w d19jDxl0dwJCcTBx Y0ZrVj5cCUUrIBUv QlNTHDlQeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4zBD8i ThsTVTwpEQUPQyI4 LBcmI18aVEoYLkxa 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: 1W1Z3Q-0000xg-7R Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Privacy and blockchain data 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, 10 Jan 2014 10:11:05 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 07, 2014 at 10:34:46PM -0800, Jeremy Spilman wrote: > > > >2) Common prefixes: Generate addresses such that for a given wallet they > > all share a fixed prefix. The length of that prefix determines the > > anonymity set and associated privacy/bandwidth tradeoff, which > > remainds a fixed ratio of all transactions for the life of the > > wallet. > > >=20 > Interesting thought to make the privacy/bandwidth trade-off using > vanitygen and prefix filters. >=20 > But doesn't this effectively expand the universe of potential spies > from 'the global attacker' who is watching your SPV queries, to > simply 'the globe' -- anyone with a copy of the blockchain? It's a trade-off. Most people are going to use public peers for their SPV nodes - they're not going to run full nodes. They also are going to want to limit how much bandwidth they use to sync their wallets; if they don't care the can use a very short, or no, prefix and the problem goes away. If you make that bandwidth/privacy trade-off by using very specific filters and non-specific addresses then you have a situation where those public peers are learning a lot of potentially valuable data. It's easy to imagine, say, the IRS being willing to pay for data on how many Bitcoins people have in their wallets to try to catch tax cheats for instance, and that can easily fund a lot of fast and high-quality peers that don't advertise the fact that they're selling data on the contents of your wallet. On the other hand if you use non-specific filters, and prefixed addresses for incoming payments, then you're not leaking high-quality information to anyone. I think this makes for a more robust Bitcoin system, especially as we need things like CoinJoin for privacy that make *everyones* privacy matter to you; CoinJoin could easily be defeated by aquiring lots of good info on the contents of wallets through SPV queries. > Some stats on UTXO set size: (slightly stale -- as of block 270733) >=20 > 7.4m unspent outputs > 2.2m transactions with unspent outputs > 2.1m unique unspent scriptPubKeys > Side note: the top 1,000 scriptPubKeys have 10% of all unspent outputs. >=20 > Let's say you use an 8-bit prefix (1/256) that would be ~10,000 > transactions in the UTXO you would be monitoring. But if I knew a > few different days / time-periods you transacted, I could figure out > your prefix. Actually UTXO isn't the right way to look at this; prefix filters would be almost certainly matched against all txouts in blocks. Or put another way, UTXO isn't the right way to look at it because the attacker will have some rough idea of the time period, and wants to know about transactions made. > Of course, anyone you transact with would know your prefix outright. Well what good, in your example, is it for the attacker to go from "I know my target gets a paycheck every two weeks for $x" to "His wallet prefix is abcd with y% probability"? Even once you learn the prefix of your target's wallet, what funds they actually own is still embedded in a much larger anonymity set of hundreds to thousands of transactions that had nothing to do with them. > Wouldn't this also allow obvious identification of spend versus > change addresses in a transaction? No, I specifically said that you don't want to use prefixes with change txouts for that reason. Fortunately while the set of all scriptPubKey's ever used for change txouts will grow over time, as long as you are not watching for new payments on any key in that set you only need to query for the ones that still have funds on them, and that's only because you want to be able to detect unauthorized spends of them. --=20 'peter'[:-1]@petertodd.org 00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGrBAEBCACVBQJSz8cqXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDI4YTVjOWVkYWJjOTY5N2ZlOTY0MDVmNjY3YmUxZDZkNTU4 ZDFkYjIxZDQ5Yjg4NTcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuIxQf7Bw9tzQSlzudcVXExSD58tO1m pDSI+fMSGtfMKrD9Be0vS3ys5t48X1t1gP0vguh8QzyUi8vrJXjdpz73SwFEk9Y0 3d7l3HgkQUla5LGriWs/zPBUrm5nlyOv7UPHjo+kfUzWG4U8lJpuIr61AUkwZRQp gi0LKlF+1iO3+5+zU5t40Xezsa0yA/b6kx8aEi7qa8EkEeeLj2cwmowa3/OzH0am r/Yk49dyIIDFzWjnjYvOMpiZfH+a+JjBaMRf+LtjzZrAScV6bLb2Z5aUo3A3UIWZ ARYhf0iuht9qA1qJXDB4gyt4F0jbwPdKdPz8rOTCmQTwPwF5MkFxEYm28rFL0g== =woB4 -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--