summaryrefslogtreecommitdiff
path: root/9c/3f827c6831898c30cb66b9df499ef5359dcd32
blob: bd242fc324375e8b6070b27e7c9abaf8022a9d98 (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
	id 1W7Xgt-0006ih-CD for bitcoin-development@lists.sourceforge.net;
	Sun, 26 Jan 2014 21:56:31 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
Received: from plane.gmane.org ([80.91.229.3])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1W7Xgs-0002li-Dn
	for bitcoin-development@lists.sourceforge.net;
	Sun, 26 Jan 2014 21:56:31 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
	id 1W7Xgl-0005hR-Hb for bitcoin-development@lists.sourceforge.net;
	Sun, 26 Jan 2014 22:56:23 +0100
Received: from f052020014.adsl.alicedsl.de ([78.52.20.14])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
	Sun, 26 Jan 2014 22:56:23 +0100
Received: from andreas by f052020014.adsl.alicedsl.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 26 Jan 2014 22:56:23 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Sun, 26 Jan 2014 22:56:11 +0100
Message-ID: <lc409d$4mf$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f052020014.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
X-Spam-Score: -0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [80.91.229.3 listed in list.dnswl.org]
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	1.1 DKIM_ADSP_ALL          No valid author signature,
	domain signs all mail
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1W7Xgs-0002li-Dn
Subject: [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: Sun, 26 Jan 2014 21:56:31 -0000

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.