Seems like Greg & I may be saying different things. Maybe I am
misunderstanding something at the wire level or in size/scalability
but what I was trying to say is I think simpler.
By UTXO commitment I mean a merkle tree of unspent addresses is
committed in each block. Also a bloom filter contain
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
>
> 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 Greg
On Fri, Feb 20, 2015 at 5:59 PM, Adam Back 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 people think of the co
>
> 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
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
>
> 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 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 having a high
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. Perhap
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? S
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 wrote:
> Hello,
>
> I want to im
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 Actuate!
On Feb 20, 2015, at 5:18 PM, Wladimir 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 hear it) but
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 issu
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
h
15 matches
Mail list logo
