[Bitcoin-development] ECDH in the payment protocol

Peter Todd pete at petertodd.org
Fri May 9 15:27:15 UTC 2014


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 design, which is why I'm now proposing it
> instead. I think you made the wrong design call, but at any rate, it's
> something reasonable people can disagree on.
> 
> Payment messages are sent directly to the merchant, who takes
> responsibility for broadcast. Once you delivered transactions to the
> merchant successfully, from your perspective the payment is made. A good
> store and forward network doesn't allow messages to go missing - email is
> an example of that (ignoring spam filters that explicitly want messages to
> go missing). It either gets delivered or it doesn't. So I'm not worried
> about atomicity.

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.

I haven't yet specified that mode of operation in the current draft
stealth address standard, however I do plan on adding it. Notably the
standard is designed to allow exactly that feature to be added in a
backwards compatible way - senders who don't implement that feature, or
choose not to use it, simply fall back to op-return.

-- 
'peter'[:-1]@petertodd.org
00000000000000004d25218420094fda0891fe1d734e1a8df581bd6de7f2d0cd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140509/bdbc414c/attachment.sig>


More information about the bitcoin-dev mailing list