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: Fri, 20 Feb 2015 18:43:20 +0100 [thread overview]
Message-ID: <CANEZrP0cOY5Wt_mvBSdGGmi4NfZi04SQ7d6GLpnRxmqvXNArGA@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTFNdtUup5MB2Dc_AmQ827sM-t5yx7WQubbfOEd_bO_Ong@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
Ah, I see, I didn't catch that this scheme relies on UTXO commitments
(presumably with Mark's PATRICIA tree system?).
If you're doing a binary search over block contents then does that imply
multiple protocol round trips per synced block? I'm still having trouble
visualising how this works. Perhaps you could write down an example run for
me.
How does it interact with the need to download chains rather than
individual transactions, and do so without round-tripping to the remote
node for each block? Bloom filtering currently pulls down blocks in batches
without much client/server interaction and that is useful for performance.
Like I said, I'd rather just junk the whole notion of chain scanning and
get to a point where clients are only syncing headers. If nodes were
calculating a script->(outpoint, merkle branch) map in LevelDB and allowing
range queries over it, then you could quickly pull down relevant UTXOs
along with the paths that indicated they did at one point exist. Nodes can
still withhold evidence that those outputs were spent, but the same is true
today and in practice this doesn't seem to be an issue.
The primary advantage of that approach is it does not require a change to
the consensus rules. But there are lots of unanswered questions about how
it interacts with HD lookahead and so on.
[-- Attachment #2: Type: text/html, Size: 1560 bytes --]
next prev parent reply other threads:[~2015-02-20 17:43 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 [this message]
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=CANEZrP0cOY5Wt_mvBSdGGmi4NfZi04SQ7d6GLpnRxmqvXNArGA@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