public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
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 16:12:18 -0500	[thread overview]
Message-ID: <20140128211218.GE22059@savin> (raw)
In-Reply-To: <CANEZrP0TiZMzNei2R-cBHGLxF4ts5Pe1_U4V6iQFV7y+Eu_MAA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]

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.
> 
> 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.

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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

  reply	other threads:[~2014-01-28 21:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-26 21:56 [Bitcoin-development] BIP70: PaymentACK semantics 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
2014-01-28 21:12                   ` Peter Todd [this message]
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=20140128211218.GE22059@savin \
    --to=pete@petertodd.org \
    --cc=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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