From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wimi8-00054f-VU for bitcoin-development@lists.sourceforge.net; Fri, 09 May 2014 15:27:45 +0000 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; Received: from outmail149058.authsmtp.co.uk ([62.13.149.58]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Wimi7-00061Q-SJ for bitcoin-development@lists.sourceforge.net; Fri, 09 May 2014 15:27:44 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s49FRbmW022941; Fri, 9 May 2014 16:27:37 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s49FRRve084212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 9 May 2014 16:27:30 +0100 (BST) Date: Fri, 9 May 2014 11:27:15 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20140509152715.GA12421@savin> References: <20140509150325.GA30436@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 6f8bf174-d78e-11e3-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgsUFVQNAgsB AmIbWlJeUlp7WmM7 bAxPbAVDY01GQQRq WVdMSlVNFUsrBRV3 ZHxYBxl6cwdHejB5 bEZkEHYNVBYsdEF5 XxpTHTgbZGY1a31N U0leagNUcgZDfk5E bwQuUz1vNG8XDQg5 AwQ0PjZ0MThBJSBS WgQAK04nCWsgMh50 RhZKATUiVVUMViA+ KQBuMkQbAEEaNUFa X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Wimi7-00061Q-SJ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] ECDH in the payment protocol X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:27:45 -0000 --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--