From: Peter Todd <pete@petertodd•org>
To: Adam Back <adam@cypherspace•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] NODE_BLOOM service bit
Date: Fri, 6 Jun 2014 05:04:41 -0400 [thread overview]
Message-ID: <20140606090441.GA19256@savin> (raw)
In-Reply-To: <20140606084852.GA30247@netbook.cypherspace.org>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote:
> Advertising NODE BLOOM as a service sounds good.
>
> But the critique of bloom filters, I am not so sure prefix filters are
> better. 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 - if you
don't do that they have privacy equal or better than bloom filters, but
with better scalability. 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.
> All for scalability, efficiency and decentralization but not ideally at the
> expense of nuking privacy. The effects on privacy are cumulative, and
> affect everyone not just the user. Same pattern of local decision, global
> effect as with reused addresses.
Indeed. But again, remember that the existing systems suck too;
prefix-brute forcing is a engineering tradeoff implementable with
existing and well understood technology.
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. Stealth addresses at least have been
designed so that future blockchain filter upgrades can be added in a
backwards compatible way.
--
'peter'[:-1]@petertodd.org
00000000000000003a68ee16d702ca5dd5547fb4aead910a004747cb06241dd6
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-06-06 9:03 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 [this message]
2014-06-06 10:45 ` Adam Back
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=20140606090441.GA19256@savin \
--to=pete@petertodd$(echo .)org \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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