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.

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 they don't recognise it or the tx never confirms or whatever. It's grotty manual work but they do it. Not broadcasting unless you "have" to seems like an optimisation that can reduce pain without much additional complexity.



On Tue, Jan 28, 2014 at 6:23 PM, Peter Todd <pete@petertodd.org> wrote:
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:
>
> > 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 via
> > HTTP, I think.
> >
>
> 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.
>
> 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.
>
> And even if you don't care about CoinJoin, not broadcasting the transaction
> as soon as the inputs are signed adds implementation complexity (should you
> 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.
From 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.

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