Received-SPF: pass (sog-mx-2.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: Tue, 28 Jan 2014 16:12:18 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140128211218.GE22059@savin>
References: <lc409d$4mf$1@ger.gmane.org>
	<CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com>
	<CANEZrP0ENhJJhba8Xwj_cVzNKGDUQriia_Q=JWTXpztb6ic8rg@mail.gmail.com>
	<CAEY8wq4QEO1rtaNdjHXR6-b3Cgi7pfSWk7M8khVi0MHCiVOBzQ@mail.gmail.com>
	<CAPg+sBgUNYqYm7d4Rv+f0rBa=nSuqwmZ6_REBS7M-+Wea+za0g@mail.gmail.com>
	<CAEY8wq6n_27Y2N7fVw9uJkfiiYqi6JkTwO0q03_J7tUeBhdQYA@mail.gmail.com>
	<CANEZrP0HVJ7Uzow1=4-20LnejURqO5uo16H43uhL=TtNfzhAxQ@mail.gmail.com>
	<CABsx9T2ng9vGMmfFK95A1jBK-FotDL-fA1oOt-=zosCPaug-rQ@mail.gmail.com>
	<20140128172349.GA14168@savin>
	<CANEZrP0TiZMzNei2R-cBHGLxF4ts5Pe1_U4V6iQFV7y+Eu_MAA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="KuLpqunXa7jZSBt+"
Content-Disposition: inline
In-Reply-To: <CANEZrP0TiZMzNei2R-cBHGLxF4ts5Pe1_U4V6iQFV7y+Eu_MAA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andreas Schildbach <andreas@schildbach.de>,
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
Precedence: list


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

On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
> In practice this should only be an issue if a payment is submitted and
> fails, which should be rare. Barring internal server errors and screwups =
on
> the merchants side, the only reasons for a rejection at submit time would
> be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
> dust tx or one that's invalid/too low fee/etc.
>=20
> So I think we have a bit of time to figure this out. But yes - once you
> broadcast, you probably accept that there might be a more painful path to
> resolve issues if something goes wrong, I guess. Right now BitPay has a
> support system where you can file a ticket if you pay the bitcoins and th=
ey
> don't recognise it or the tx never confirms or whatever. It's grotty manu=
al
> work but they do it. Not broadcasting unless you "have" to seems like an
> optimisation that can reduce pain without much additional complexity.

That's the reason you use a model where things happen atomicly: the
funds either can or can't be transferred, so if the merchant screws up
due to a server failure at worst the wallet can always send the
original, signed, payment request and transaction details proving to the
merchant that they agreed. Since the asked for txouts exist in the
blockchain they must either refund the money, or ship the goods.

Wallet software can handle that kind of worst-case failure by
automatically sending the original payment request back to the merchant.
At worst all customer support has to do is tell the customer "Sorry
about that; we didn't get your payment. Please start your wallet up and
hit the 'resend transaction' button in your wallet and we'll clear that
right up."

Keep in mind that we're probably going to see fraudsters figuring out
ways to make payment servers fail. This means conversely that a customer
calling up a merchant and saying "Hey! Something didn work but the
wallet says I paid!" is going to be treated more suspiciously. By using
atomic protocols the issue of did or didn't they pay becomes much more
black and white, and failure resistant. That's exactly what we keep
saying Bitcoin offers that PayPal doesn't.

--=20
'peter'[:-1]@petertodd.org
000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925

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

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

iQGrBAEBCACVBQJS6B0xXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA4NWM3MjVhOTA1NDQ0ZDI3MWM1NmZkZWU0ZTRlYzdmMjdi
ZGIyZTc3N2M4NzI5MjUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfu+TAf/diHpRv0a8Izo9+qY8qu2zLTZ
GMfj6KRuDTzfTKtXEH7Vr6tRbIqjuUOxC5WrSmikmsk9Hl4ryunoBPrm2HT+/7DG
gLLFM7jebpyE+Iu+ONgsq7brseUbM1bjw9lDYYFkk3LtmnzrA5l5S+3gQ/kUSmyI
KnKdO0Y+iUJTDaYWM5vRKJijzYB5mbubXJ/9CmVuNA/JY+toCtSCumIXKbfyFsmD
A8B5hyMjpCYA2btIQC1aNAW509XxCRTfEr5Q7d8MSRteyf0nxGfARdGcxMQDYGGL
A6uym/jdJmko4VGGmDkM2AgnHHQ2TbZa1pZUyS2A9nBLUYiB9KpxZ+bd50n4aA==
=xdu1
-----END PGP SIGNATURE-----

--KuLpqunXa7jZSBt+--