From: Adam Back <adam@cypherspace•org>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] NODE_BLOOM service bit
Date: Fri, 6 Jun 2014 12:45:43 +0200 [thread overview]
Message-ID: <20140606104543.GA31085@netbook.cypherspace.org> (raw)
In-Reply-To: <20140606090441.GA19256@savin>
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
next prev parent reply other threads:[~2014-06-06 10:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 8:19 Peter Todd
2014-06-06 8:48 ` Adam Back
2014-06-06 9:03 ` Gregory Maxwell
2014-06-06 9:11 ` Peter Todd
2014-06-06 9:04 ` Peter Todd
2014-06-06 10:45 ` Adam Back [this message]
2014-06-06 16:46 ` [Bitcoin-development] Bloom bait Peter Todd
2014-06-06 16:58 ` Gregory Maxwell
2014-06-06 17:05 ` Peter Todd
2014-06-06 17:10 ` Gregory Maxwell
2014-06-06 17:45 ` Peter Todd
2014-06-07 11:22 ` Mike Hearn
2014-06-07 19:44 ` Alan Reiner
2014-06-08 21:45 ` Peter Todd
2014-06-10 10:41 ` Mike Hearn
2014-06-08 21:35 ` Peter Todd
2014-06-10 10:38 ` Mike Hearn
2014-06-10 13:02 ` Jeff Garzik
2014-06-10 17:08 ` Peter Todd
2014-06-11 8:57 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140606104543.GA31085@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox