Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty
efficient. The downside is it relies entirely on Tor for privacy, but
then again it's not the only aspect of spv clients that require it for
privacy (there's
Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty efficient.
No, I think it's less efficient (for the client).
Quick sums: blocks with 1500 transactions in them are common today. But
Bitcoin is growing.
Yeah that overhead is pretty high. I wasn't thinking about 10 years out.
On Sat, Feb 21, 2015, 11:47 AM Mike Hearn m...@plan99.net wrote:
Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty efficient.
No,
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
If you want to be constructive and index transactions that are not
p2sh but non-simple and contain checksig so the address is visible,
you could do that with a block bloom filter also.
I wasnt sure if the comments about the need to batch requests was
about downloading headers filters, or about
Hello Adam,
On Fri, 20 Feb 2015, Adam Back wrote:
So I was wondering what about changing to committing a bloom filter of
the addresses in the block. 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
On Feb 20, 2015, at 5:18 PM, Wladimir laa...@gmail.com wrote:
On Fri, 20 Feb 2015, Adam Back wrote:
So I was wondering what about changing to committing a bloom filter of
the addresses in the block. Its seems surprising no one thought of it
that way before (as it seems obvious when you
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
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.
This is talking about a committed bloom filter. Not a committed UTXO set.
I read the following comment to mean it requires the UTXO commitments.
Otherwise I'm not sure how you prove absence of withholding with just
current block structures+an extra filter included in the block:
but with the
On Fri, Feb 20, 2015 at 4:54 PM, Mike Hearn m...@plan99.net wrote:
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
This approach needs a filter set with a lower FP rate. It doesn't
depend on
The idea is not mine, some random guy appeared in #bitcoin-wizards one
day and said something about it, and lots of people reacted, wow why
didnt we think about that before.
It goes something like each block contains a commitment to a bloom
filter that has all of the addresses in the block stored
So now they ask a full node for merkle paths + transactions for the
addresses from the UTXO set from the block(s) that it was found in.
This is the part where I get lost. How does this improve privacy? If I have
to specify which addresses are mine in this block, to get the tx data, the
node
On Fri, Feb 20, 2015 at 5:59 PM, Adam Back a...@cypherspace.org wrote:
So now they ask a full node for merkle paths + transactions for the
addresses from the UTXO set from the block(s) that it was found in.
Use of the words UTXO set here is probably confusing people as it's
likely to make
It's a straight forward idea: there is a scriptpubkey bitmap per block
which is committed. Users can request the map, and be SPV confident
that they received a faithful one. If there are hits, they can request
the block and be confident there was no censoring.
OK, I see now, thanks Gregory.
15 matches
Mail list logo
