Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-13 Thread Jeff Garzik
On Fri, May 9, 2014 at 11:03 AM, Peter Todd p...@petertodd.org wrote: Of course we quickly rejected the idea of depending solely on a communications backchannel to retrieve funds. Any communications medium that isn't the blockchain makes the payment non-atomic, and thus creates opportunities

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-13 Thread Mike Hearn
On Tue, May 13, 2014 at 12:40 AM, Chris Pacia ctpa...@gmail.com wrote: Just a thought. Using the payment protocol for stealth would mean we would likely have to return to backing up wallets all the time would it not? I think you are right. Awkward. Wallets could auto-respend transactions to

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-12 Thread Peter Todd
On Fri, May 09, 2014 at 08:38:22PM +0200, Pieter Wuille wrote: On Fri, May 9, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote: I don't think we're going to find that's practical unfortunately due to change. Every payment I make ties up txouts, so if we try to base the atomicity of

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-12 Thread Chris Pacia
Just a thought. Using the payment protocol for stealth would mean we would likely have to return to backing up wallets all the time would it not? The nonces cannot be derived from your wallet seed and, since they aren't in the blockchain, would have to be stored in your wallet. I suppose they

[Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Mike Hearn
I wrote an article about an ECDH extension for BIP 70: https://medium.com/p/cb2f81962c1b The article is meant for people who don't follow bitcoin-development so I'll summarise it here: - The notion of being able to publish a piece of data once and use it to receive lots of payments

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Peter Todd
On Fri, May 09, 2014 at 02:05:24PM +0200, Mike Hearn wrote: It's always interesting to see the reinvention cycle happen in the Bitcoin space as ideas get proposed over and over again; I'm sure Amir Taaki will be pleased to read this as it is a slightly less sophisticated version of what he

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Mike Hearn
Of course we quickly rejected the idea of depending solely on a communications backchannel to retrieve funds. Any communications medium that isn't the blockchain makes the payment non-atomic Yes, I know you rejected this design, which is why I'm now proposing it instead. I think you made the

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Peter Todd
On Fri, May 09, 2014 at 05:15:52PM +0200, Mike Hearn wrote: Of course we quickly rejected the idea of depending solely on a communications backchannel to retrieve funds. Any communications medium that isn't the blockchain makes the payment non-atomic Yes, I know you rejected this

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Mike Hearn
Ah, you're still misunderstanding my point: You can get atomicity in the worst-case where the communications medium fails *and* stealth payments that use up no extra space in the blockchain. This gives you the best of both worlds. Sounds great! How does a lightweight client identify such

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Pieter Wuille
I believe stealth addresses and the payment protocol both have their use cases, and that they don't overlap. If you do not want to communicate with the receiver, you typically do not want them to know who is paying or for what (otherwise you're already talking to them in some way, right?). That's

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Pieter Wuille
On Fri, May 9, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote: I don't think we're going to find that's practical unfortunately due to change. Every payment I make ties up txouts, so if we try to base the atomicity of payments on whether or not the payee decides to broadcast the