brittleness. The real world experience is that users, or to be exact
wallet authors, turn down SPV privacy parameters until bloom filters
have almost no privacy in exchange for little bandwidth usage.
That's not fundamental though, it just reflects that the only
implementation of this is
On Fri, Jan 24, 2014 at 12:26:19PM +, Mike Hearn wrote:
brittleness. The real world experience is that users, or to be exact
wallet authors, turn down SPV privacy parameters until bloom filters
have almost no privacy in exchange for little bandwidth usage.
That's not fundamental
I think prefix has analysis side effects. There are (at least) 4 things
that link payments: the graph of payment flows, timing, precise amounts, IP
addresses, but with prefix a 5th: the prefix allows public elmination of
candidates connections, I think that may make network flow analysis even
On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote:
I think prefix has analysis side effects. There are (at least) 4 things
that link payments: the graph of payment flows, timing, precise amounts, IP
addresses, but with prefix a 5th: the prefix allows public elmination of
candidates
I think we need to provide users with better options than that.
Perfect privacy without extraordinary computational overhead today means
downloading everything. But we could provide better tools to *shift* bandwidth
requirements rather than try to reduce them.
I've been thinking
One challenge with reusable addresses is that while they result in a
small constant overhead for full nodes in searching for their own
transactions they create large overheads for SPV nodes.
One way to address this is for the SPV nodes to hand their servers
their blinding private key so that the
6 matches
Mail list logo
