1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1W7nZt-0003VU-CG
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 14:54:21 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.42 as permitted sender)
client-ip=74.125.82.42; envelope-from=gavinandresen@gmail.com;
helo=mail-wg0-f42.google.com;
Received: from mail-wg0-f42.google.com ([74.125.82.42])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W7nZp-0007oq-59
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 14:54:21 +0000
Received: by mail-wg0-f42.google.com with SMTP id l18so4269492wgh.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 27 Jan 2014 06:54:09 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.79.73 with SMTP id h9mr10528380wix.3.1390834449451; Mon,
27 Jan 2014 06:54:09 -0800 (PST)
Received: by 10.194.10.197 with HTTP; Mon, 27 Jan 2014 06:54:09 -0800 (PST)
In-Reply-To: <lc409d$4mf$1@ger.gmane.org>
References: <lc409d$4mf$1@ger.gmane.org>
Date: Mon, 27 Jan 2014 09:54:09 -0500
Message-ID: <CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=f46d041825e24d118104f0f4e17a
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1W7nZp-0007oq-59
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2014 14:54:21 -0000
--f46d041825e24d118104f0f4e17a
Content-Type: text/plain; charset=ISO-8859-1
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
--f46d041825e24d118104f0f4e17a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jan 26, 2014 at 4:56 PM, Andreas Schildbach <span dir=3D"ltr"><<a hr=
ef=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildbach.de=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The BIP70 is very brief on what a PaymentACK=
is supposed to mean. Quote:<br>
<br>
"it [PaymentACK] is sent from the merchant's server to the bitcoin=
<br>
wallet in response to a Payment message"<br>
<br>
Does it simply mean we received a syntactically correct Payment message?<br=
></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Does it mean the Payment is va=
lid?<br>
Does it mean the Payment is valid and confirmed?<br>
How long can we delay the ack until all conditions for payment are met?<br>
I assume its not a good idea to keep the HTTP (or Bluetooth, for that<br>
matter) connection open for an hour while waiting for a blockchain<br>
confirmation.<br></blockquote><div><br></div><div>The purpose of PaymentACK=
is to give the customer reassurance that their payment request has been re=
ceived and will be processed (or not).</div><div><br></div><div>If it is sy=
ntactically incorrect or invalid in a way that the payment processor can de=
tect right away then a PaymentACK with a message saying that there is a pro=
blem should be the response.</div>
<div><br></div><div>Waiting until confirmed is definitely not the right thi=
ng to do, but waiting a few seconds to detect a 0-confirmation double-spend=
attempt before sending back an ACK is fine. =A0The BIP is intentionally va=
gue on how long it might take to get an ACK, but, again, the intent is to g=
ive the customer reassurance that their payment was received and is being p=
rocessed, 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").</div=
>
<div><br></div><div>=A0</div></div>--<br>Gavin Andresen<br>
</div></div>
--f46d041825e24d118104f0f4e17a--
|
