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; 
Date: Tue, 28 Jan 2014 12:23:49 -0500
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20140128172349.GA14168@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o"
Content-Disposition: inline
In-Reply-To: <CABsx9T2ng9vGMmfFK95A1jBK-FotDL-fA1oOt-=zosCPaug-rQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
Precedence: list


--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 <mike@plan99.net> 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--