Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Mike Hearn
I've thought about [ab]using Tor as a STUN replacement before, but the issue is a lot of people don't have computers that are switched on all the time anymore except for their smartphones, which are too weak to calculate the UTXO set. The trend has been for a while towards laptops, phones and table

Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Jeremy Spilman
> > > > 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

Re: [Bitcoin-development] BIP0039: Final call

2014-01-24 Thread Thomas Voegtlin
Le 24/01/2014 10:05, Peter Todd a écrit : > On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote: >> Hi slush, >> >> Thank you for your new proposal; it seems to be a compromise. >> >> @Christophe Biocca: >> If the wordlist becomes part of the standard, then we will run into >> problems

Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Peter Todd
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

Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Adam Back
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 more

Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Peter Todd
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 fun

Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Mike Hearn
> > 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

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

2014-01-24 Thread Peter Todd
On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote: > Let's say the payee's reusable address is ' > ...', where is 2 bytes. Without any length indicator. What's the > payer going to put on the blockchain? How would they know what the 'rest > of the space' is? They would have t

Re: [Bitcoin-development] BIP0039: Final call

2014-01-24 Thread Peter Todd
On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote: > Hi slush, > > Thank you for your new proposal; it seems to be a compromise. > > @Christophe Biocca: > If the wordlist becomes part of the standard, then we will run into > problems of collisions once users ask for wordlists in eve

Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Peter Todd
On Wed, Jan 15, 2014 at 05:23:04PM -0800, Gregory Maxwell wrote: > It also has a downside of not being indexable for the server, the > server must do O(clients * reusable-address-txn) work and the work > includes an ECC multiply. > > An idea that Adam Back had originally proposed was including opt