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 ) 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 ) 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 ; 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 ; Sun, 26 Jan 2014 22:56:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Sun, 26 Jan 2014 22:56:11 +0100 Message-ID: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.