From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8FxR-0005ii-Tp for bitcoin-development@lists.sourceforge.net; Tue, 28 Jan 2014 21:12:33 +0000 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; Received: from outmail149058.authsmtp.co.uk ([62.13.149.58]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W8FxQ-0003KE-KF for bitcoin-development@lists.sourceforge.net; Tue, 28 Jan 2014 21:12:33 +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 s0SLCPbK021613; Tue, 28 Jan 2014 21:12:25 GMT 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 s0SLCItf000187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 28 Jan 2014 21:12:20 GMT Date: Tue, 28 Jan 2014 16:12:18 -0500 From: Peter Todd To: Mike Hearn Message-ID: <20140128211218.GE22059@savin> References: <20140128172349.GA14168@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KuLpqunXa7jZSBt+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: e08abad4-8860-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdAoUElQaAgsB AmIbWVVeUV97W2I7 bAxPbAVDY01GQQRq WVdMSlVNFUsrAX99 dWdaBBlydwROfzBy Z0BmXj4OXEwrJxcp RlNcHWsGeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4hPwZj H0JKJTw+GEADWwwY DFQ9J1sVGloQOV5a 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: 1W8FxQ-0003KE-KF Cc: Andreas Schildbach , Bitcoin Dev Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics 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: Tue, 28 Jan 2014 21:12:34 -0000 --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+--