Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8COK-0006R6-26 for bitcoin-development@lists.sourceforge.net; Tue, 28 Jan 2014 17:24:04 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.106 as permitted sender) client-ip=62.13.148.106; envelope-from=pete@petertodd.org; helo=outmail148106.authsmtp.co.uk; Received: from outmail148106.authsmtp.co.uk ([62.13.148.106]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W8COI-0007wY-6g for bitcoin-development@lists.sourceforge.net; Tue, 28 Jan 2014 17:24:04 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0SHNsx3014690; Tue, 28 Jan 2014 17:23:54 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 s0SHNnkY090285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 28 Jan 2014 17:23:52 GMT Date: Tue, 28 Jan 2014 12:23:49 -0500 From: Peter Todd To: Gavin Andresen Message-ID: <20140128172349.GA14168@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: f569f8f4-8840-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdAoUElQaAgsB AmIbWlNeUl57XGE7 bAxPbAVDY01GQQRq WVdMSlVNFUsrAX95 eEBFOxl7dwdOfTBy Z0ZhXj4NWUJzI04r RlNcHWkGeGZhPWMC 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: 1W8COI-0007wY-6g Cc: Bitcoin Dev , Andreas Schildbach 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 17:24:04 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote: > On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn wrote: >=20 > > Yeah, that's the interpretation I think we should go with for now. There > > was a reason why this isn't specified and I forgot what it was - some > > inability to come to agreement on when to broadcast vs when to submit v= ia > > HTTP, I think. > > >=20 > If the wallet software is doing automatic CoinJoin (for example), then > typically one or several of the other participants will broadcast the > transaction as soon as it is complete. >=20 > If the spec said that wallets must not broadcast until they receive a > PaymentACK (if a payment_url is specified), then you'd have to violate the > spec to do CoinJoin. >=20 > And even if you don't care about CoinJoin, not broadcasting the transacti= on > as soon as the inputs are signed adds implementation complexity (should y= ou > retry if payment_url is unavailable? how many times? if you eventually > unlock the probably-not-quite-spent-yet inputs, should you double-spend > them to yourself just in case the merchant eventually gets around to > broadcasting the transaction, or should you just unlock them and squirrel > away the failed Payment so if the merchant does eventually broadcast you > have a record of why the coins were spent). Also users don't have infinite unspent txouts in their wallets - if they need to make two payments in a row and run out their wallet software is (currently) going to spend the change txout and either be forced to broadcast both transactions anyway, or the second payment-protocol-using recipient will do so on their behalf. (in the future they might also do a replacement tx replacing the first with a single tx paying both to save on fees, again with the same problem) Anyway what you want is payment atomicity: the customer losing control of the funds must be atomic with respect to the payment going through. =46rom that point of view it's unfortunate that Payment message contains refund_to, memo, etc. That information should have been provided to the merchant prior to them providing the list of addresses to pay. --=20 'peter'[:-1]@petertodd.org 000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925 --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGrBAEBCACVBQJS5+ekXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA4NWM3MjVhOTA1NDQ0ZDI3MWM1NmZkZWU0ZTRlYzdmMjdi ZGIyZTc3N2M4NzI5MjUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvgawf/QRLs1/9UNwVtb6kN+e2QQPAJ FG9SfOAU3MOB7np/HkhEpqRZew5u0cLAUni/b1p30GVpbvh5yujIAJvNkOfH1hDC ysRHFSqfeUbB+Vemt6v4EO33/T4Lj5BqleY1DhqXni2BJ75mk0AHw5h2nzYXFbZV U+j3AXokG+6ShszapL+wCZUcBMuKtRVZYzhq1aCGKCQL8kmZHeU+dKhiGM0IwSQU xeWjWGZqZoG/r6QQlGs8Z+RCnpvIQXncbnNGGIzHG4X+OKclVoyRLtZ/Tn5nx7EU u6xdKG3+STR4j//hl+srT3QrT6fOYJpLhMWc52NGx7Ku4rQgApNZCEmD0bqSjQ== =bkXh -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o--