From: Mike Hearn <mike@plan99•net>
To: Peter Todd <pete@petertodd•org>
Cc: Andreas Schildbach <andreas@schildbach•de>,
Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
Date: Tue, 28 Jan 2014 18:33:28 +0100 [thread overview]
Message-ID: <CANEZrP0TiZMzNei2R-cBHGLxF4ts5Pe1_U4V6iQFV7y+Eu_MAA@mail.gmail.com> (raw)
In-Reply-To: <20140128172349.GA14168@savin>
[-- Attachment #1: Type: text/plain, Size: 3268 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4068 bytes --]
next prev parent reply other threads:[~2014-01-28 17:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-26 21:56 Andreas Schildbach
2014-01-27 14:54 ` Gavin Andresen
2014-01-27 15:20 ` Andreas Schildbach
2014-01-27 15:52 ` Mike Hearn
2014-01-27 22:03 ` Kevin Greene
2014-01-27 22:17 ` Pieter Wuille
2014-01-27 22:39 ` Kevin Greene
2014-01-28 11:42 ` Mike Hearn
2014-01-28 12:53 ` Gavin Andresen
2014-01-28 13:09 ` Pieter Wuille
2014-01-28 13:24 ` Mike Hearn
2014-01-28 17:23 ` Peter Todd
2014-01-28 17:33 ` Mike Hearn [this message]
2014-01-28 21:12 ` Peter Todd
2014-01-30 14:51 ` Jeff Garzik
2014-01-30 14:58 ` Pieter Wuille
2014-01-30 15:01 ` Mike Hearn
2014-01-30 15:06 ` Gavin Andresen
2014-01-30 15:16 ` Pieter Wuille
2014-01-30 20:16 ` Jeremy Spilman
2014-01-31 4:16 ` Chuck
2014-01-31 16:21 ` Christophe Biocca
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP0TiZMzNei2R-cBHGLxF4ts5Pe1_U4V6iQFV7y+Eu_MAA@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox