From: Mike Hearn <mike@plan99•net>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] bloom filtering, privacy
Date: Sat, 21 Feb 2015 15:45:07 +0100 [thread overview]
Message-ID: <CANEZrP1feonDYtC0J2w12bV_59fBsmJkKkPN7oM1=WMqSZx2jw@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTHqrYvYcGDsKkwwSrJ7J0qr_kBjKHmFgO4Bmmkodydw0g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]
>
> For downloading transactions unless you frequently receive
> transactions you wont be fetching every block. Or are you assuming
> bloom filters dialled up to the point of huge false positives? You
> said otherwise.
>
Well, what I mean is, bitcoinj already gets criticised for having very low
FP rates, but even with those rates we're applying them to hundreds of
thousands of transactions per sync. So it's still enough FPs to trigger at
least one per block, often several, yet people tell us this isn't enough to
give meaningful privacy.
> Relatedly I think bitcoin could do with a store-and-forward message
> bus with privacy and strong reliability via redundancy (but less
> redundancy maybe than consensus all-nodes must receiving and agree and
> store forever).
>
Yup, see here:
https://www.bitcoinauthenticator.org/subspace/
https://groups.google.com/forum/#!topic/bitcoinj/_S15jo5mcDI
Subspace looks like it's developing into what we need.
> You seem to be saying at one point that Tor is useless against
> pervasive eavesdropper threat model
No, Tor is effective against in that threat model. What I meant is that
without Tor, someone doing wire intercepts isn't going to be fazed by using
multiple peers together, and with Tor it's not clear that syncing from
multiple peers in parallel gives much an additional win.
Also, getting Tor practical enough to activate by default is tricky. Though
the same people who are doing Subspace are trying it out to see what
happens.
secondly that other types of attackers are disinterested (how do we know
> that?) or maybe that you
> dont care about privacy vs them (maybe some users do!)
>
Some of my opinions are based on experience of HTTPS deployments, where
many of the same issues apply.
> It would certainly be nice to get real privacy from a wider range of
> attackers but nothing (current situation) is clearly worse; using
> block bloom filters we'd make the pervasive case harder work, and the
> nosy full node learn nothing.
Yes, but what's the best way to fix that?
The calculation goes like this: we have ~80 hours of hacking time to spend
on privacy this quarter. Do we:
a) Do wire encryption
b) Make Bloom filter clients smarter
c) Optimise Tor
d) Do a new PIR protocol from scratch and possibly run out of time having
failed to launch
Of these (d) is the least appealing to me, especially because I don't feel
like submitting SPV related stuff to Bitcoin Core any more. If I were to
work on the protocol it'd be in the context of Bitcoin XT, which rules out
consensus changes or other things that rely on miners. Wire encryption
would probably raise the bar for our spooky friends quite a lot, with
minimal effort. The ROI looks good, compared to more complex PIR.
[-- Attachment #2: Type: text/html, Size: 4283 bytes --]
next prev parent reply other threads:[~2015-02-21 14:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 12:44 Adam Back
2015-02-20 16:18 ` Wladimir
2015-02-20 16:38 ` Tamas Blummer
2015-02-20 16:54 ` Mike Hearn
2015-02-20 17:35 ` Adam Back
2015-02-20 17:43 ` Mike Hearn
2015-02-20 17:59 ` Adam Back
2015-02-20 18:10 ` Mike Hearn
2015-02-20 18:20 ` Gregory Maxwell
2015-02-20 19:03 ` Mike Hearn
2015-02-21 5:12 ` Adam Back
2015-02-21 13:28 ` Mike Hearn
2015-02-21 14:30 ` Adam Back
2015-02-21 14:45 ` Mike Hearn [this message]
2015-02-20 17:50 ` Gregory Maxwell
2015-02-20 17:53 ` Mike Hearn
2015-02-21 16:03 ` Chris Pacia
2015-02-21 16:47 ` Mike Hearn
2015-02-21 18:38 ` Chris Pacia
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='CANEZrP1feonDYtC0J2w12bV_59fBsmJkKkPN7oM1=WMqSZx2jw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--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