Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.58 as permitted sender)
	client-ip=62.13.149.58; envelope-from=pete@petertodd.org;
	helo=outmail149058.authsmtp.co.uk; 
Date: Fri, 9 May 2014 11:27:15 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140509152715.GA12421@savin>
References: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
	<20140509150325.GA30436@savin>
	<CANEZrP1m=-GWD5rLRe9vrx0JYKeKXghNw-a47ZbJTd1h3ngFww@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU"
Content-Disposition: inline
In-Reply-To: <CANEZrP1m=-GWD5rLRe9vrx0JYKeKXghNw-a47ZbJTd1h3ngFww@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
Precedence: list


--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
>=20
>=20
> 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.
>=20
> 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.

--=20
'peter'[:-1]@petertodd.org
00000000000000004d25218420094fda0891fe1d734e1a8df581bd6de7f2d0cd

--azLHFNyN32YCQGCU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTbPPPXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA0ZDI1MjE4NDIwMDk0ZmRhMDg5MWZlMWQ3MzRlMWE4ZGY1
ODFiZDZkZTdmMmQwY2QvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvU5Af/WZNMYTaALiJQDqrPZx/e+h3J
VmtwX3701pGWkXrp1L/IWU9j1POmlBuMDl/qflAUXSgFa+oqzdkJ6wWyA7Y99lHb
BKjNE4y7ojaahwxYnYhxX45xG/VGcnmYSpUHtw9fulpRy+miI6hhNhs+8JxFg19/
PA6H55u0bF4rt3RTyOjCheeEO6V6LQVIdI+6EY1oN1UaYBVy9hzc79Zhm4ig9ulc
xDJp34UZgG/OmEX47ShHu38bL5lU3cAbmA9sCjGIHqYvhfk/QXoYe5cQ6VC1lO6w
2mZQrJO3VfBZlkjNB3rE9h4/0CnpX9cGHdNd0RFeAZyqPCVV1zMjOoQ0KD0kIQ==
=qnVy
-----END PGP SIGNATURE-----

--azLHFNyN32YCQGCU--