From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
Date: Fri, 9 May 2014 11:27:15 -0400 [thread overview]
Message-ID: <20140509152715.GA12421@savin> (raw)
In-Reply-To: <CANEZrP1m=-GWD5rLRe9vrx0JYKeKXghNw-a47ZbJTd1h3ngFww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-05-09 15:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 12:05 Mike Hearn
2014-05-09 15:03 ` Peter Todd
2014-05-09 15:15 ` Mike Hearn
2014-05-09 15:27 ` Peter Todd [this message]
2014-05-09 15:34 ` Mike Hearn
2014-05-09 15:43 ` Peter Todd
2014-05-09 16:12 ` Mike Hearn
2014-05-09 15:50 ` Pieter Wuille
2014-05-09 18:13 ` Peter Todd
2014-05-09 18:38 ` Pieter Wuille
2014-05-12 13:07 ` Peter Todd
2014-05-12 22:40 ` Chris Pacia
2014-05-13 10:29 ` Mike Hearn
2014-05-13 9:19 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140509152715.GA12421@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox