I saw there was some discussion on this topic on the bitcoinj list.
(I dont think I can post there without subscribing probably.)
Someone had posted about the lack of privacy provision from the
current implementation parameters and real-world factors similar to
described in this academic paper
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
Hi Fikret,
This is the wrong mailing list for such questions. Most Bitcoin ATM's are
commercial products anyway and don't accept contributors. If you find one
that is different, it's better to contact them directly.
On Fri, Feb 20, 2015 at 5:19 PM, Fikret AKIN i...@fikretakin.com wrote:
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
Hello,
I want to improve the Bitcoin ATM, which way do you think I should continue
Do you have suggestions?
Thanks,
Fikret AKIN
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from
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.
13 matches
Mail list logo
