On Fri, Jun 06, 2014 at 05:04:41AM -0400, Peter Todd wrote: >On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote: >> Prefix filters offer questionable privacy tradeoffs in my opinion. Same >> problem as with stealth address proposed use of prefixes. > >That's assuming you're doing the proposed prefix brute forcing
As I recall prefix brute forcing was a bit twiddle saving, ie searching for 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 ineffective plausible deniability by enabling the transaction to be indistinguishable from some other (not very common) types of transaction. >don't do that they have privacy equal or better than bloom filters, but >with better scalability. 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. >In particular that better scalability lets you efficiently query multiple >servers for blockchain data, only giving up info on a subset of the >addresses in your wallet to each server. This can be a significant >improvement to bloom filters if your attacker is running logging nodes to >try to, say, deanonymize CoinJoin transactions. 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 from analysis of the public transaction graph. The latter is more damaging. 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 chance you'll be identified. Better to pick a random node, identify it and stick to it and hope you chose well. >Now if you want to come up with something better and write code, please >do! I'm sure the math exists; what doesn't exist is robust and well >tested code in multiple languages. Maybe other simpler, but yes there was the proof of concept that the math exists in the form of the weil pairing. https://bitcointalk.org/index.php?topic=431756.new But what problem are we trying to solve here? Is it an immediate problem? Maybe better to figure out a more privacy compatible solution which will take longer, than let coding drive protocol. Adam ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
