From: Adam Back <adam@cypherspace•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] bloom filtering, privacy
Date: Fri, 20 Feb 2015 17:35:47 +0000 [thread overview]
Message-ID: <CALqxMTFNdtUup5MB2Dc_AmQ827sM-t5yx7WQubbfOEd_bO_Ong@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP32M-hSU-a1DA5aTQXsx-6425sTeKW-m-cSUuXCYf+zuQ@mail.gmail.com>
Mike Hearn wrote:
> Adam Back wrote:
> > Its seems surprising no one thought of it
> > that way before (as it seems obvious when you hear it) but that seems
> > to address the privacy issues as the user can fetch the block bloom
> > filters and then scan it in complete privacy.
>
> And then what? So you know the block matches. But with reasonable FP
> rates every block will match at least a few transactions (this is already the
> case - the FP rate is low but high enough that we get back FPs on nearly
> every block). So you end up downloading every block?
I mean because the user is scanning he can binary search which set of
addresses from his wallet are possibly in the block and then request
the specific addresses and some will be false positives and some real,
but with the bloom commitment (and UTXO trie organised commitment) he
can verify that the positive hits are correct via the merkle path, and
that the false positives are not being wrongly withheld by obtaining
merkle path proof that they are not in the trie.
Adam
On 20 February 2015 at 16:54, Mike Hearn <mike@plan99•net> wrote:
> Hey Adam,
>
>>
>> Mike had posted a detailed response on the topic on why its complex
>> and becomes bandwidth inefficient to improve it usefully.
>
>
> To clarify, we could improve privacy and still preserve usefully high
> performance, it's just a lot of complicated programming work. You need to
> find out from the OS how much bandwidth you have to play with, for example,
> and do all the very complex tracking to surf the wave and keep yourself in
> roughly the right place.
>
>> The basic summary of which I think is that its not even intended to
>> provide any practical privacy protection, its just about compacting
>> the query for a set of addresses.
>
>
> The original intent of Bloom filtering was to allow both. We want our cake
> and we want to eat it.
>
> The protocol can still do that, with sufficiently smart clients. The problem
> is that being sufficiently smart in this regard has never come to the top of
> the TODO list - users are always complaining about other things, so those
> things are what gets priority.
>
> It's not IMO a protocol issue per se. It's a code complexity and manpower
> issue.
>
>>
>> Its seems surprising no one thought of it
>> that way before (as it seems obvious when you hear it) but that seems
>> to address the privacy issues as the user can fetch the block bloom
>> filters and then scan it in complete privacy.
>
>
> And then what? So you know the block matches. But with reasonable FP rates
> every block will match at least a few transactions (this is already the case
> - the FP rate is low but high enough that we get back FPs on nearly every
> block). So you end up downloading every block? That won't work.
>
> Eventually, wallets need to stop doing linear scans of the entire block
> chain to find tx data. That worked fine when blocks were 10kb, it's still
> working OK even though we scaled through two orders of magnitude, but we can
> imagine that if we reach 10mb blocks then this whole approach will just be
> too slow.
>
> The main reason wallets are scanning the chain today (beyond lack of
> protocol support for querying the UTXO set by script), is that they want to
> show users time-ordered lists of transactions. Financial apps should show
> you payment histories, everyone knows this, and without knowing roughly when
> a tx happened and which inputs/outputs were mine, providing a useful
> rendering is hard. Even with this data the UI is pretty useless, but at
> least it's not actually missing.
>
> By combining Subspace and BIP70 we can finally replace the payments list UI
> with actual proper metadata that isn't extracted from the block chain, and
> at that point non-scanning architectures become a lot more deployable.
next prev parent reply other threads:[~2015-02-20 17:35 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 [this message]
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
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=CALqxMTFNdtUup5MB2Dc_AmQ827sM-t5yx7WQubbfOEd_bO_Ong@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)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