Date: Fri, 6 Jun 2014 12:45:43 +0200
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Message-ID: <20140606104543.GA31085@netbook.cypherspace.org>
References: <20140606081933.GA29458@savin>
	<20140606084852.GA30247@netbook.cypherspace.org>
	<20140606090441.GA19256@savin>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20140606090441.GA19256@savin>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] NODE_BLOOM service bit
Precedence: list

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