From: Gavin Andresen <gavinandresen@gmail•com>
To: Andreas Schildbach <andreas@schildbach•de>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
Date: Mon, 27 Jan 2014 09:54:09 -0500 [thread overview]
Message-ID: <CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com> (raw)
In-Reply-To: <lc409d$4mf$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
On Sun, Jan 26, 2014 at 4:56 PM, Andreas Schildbach
<andreas@schildbach•de>wrote:
> The BIP70 is very brief on what a PaymentACK is supposed to mean. Quote:
>
> "it [PaymentACK] is sent from the merchant's server to the bitcoin
> wallet in response to a Payment message"
>
> Does it simply mean we received a syntactically correct Payment message?
>
Does it mean the Payment is valid?
> Does it mean the Payment is valid and confirmed?
> How long can we delay the ack until all conditions for payment are met?
> I assume its not a good idea to keep the HTTP (or Bluetooth, for that
> matter) connection open for an hour while waiting for a blockchain
> confirmation.
>
The purpose of PaymentACK is to give the customer reassurance that their
payment request has been received and will be processed (or not).
If it is syntactically incorrect or invalid in a way that the payment
processor can detect right away then a PaymentACK with a message saying
that there is a problem should be the response.
Waiting until confirmed is definitely not the right thing to do, but
waiting a few seconds to detect a 0-confirmation double-spend attempt
before sending back an ACK is fine. The BIP is intentionally vague on how
long it might take to get an ACK, but, again, the intent is to give the
customer reassurance that their payment was received and is being
processed, whatever "processed" means (order sent to shipping for
fulfillment, or awaiting 11 confirmations, or "your burger is paid for you
can leave the restaurant and we won't chase after you").
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2161 bytes --]
next prev parent reply other threads:[~2014-01-27 14:54 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 [this message]
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
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=CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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