Received-SPF: pass (sog-mx-1.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; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 27 Jan 2014 16:20:39 +0100
Message-ID: <lc5tfp$kbm$1@ger.gmane.org>
References: <lc409d$4mf$1@ger.gmane.org>
	<CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
Precedence: list

On 01/27/2014 03:54 PM, Gavin Andresen wrote:

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

Thanks for the clarification. So I am *always* supposed to reply with an
ack. I was assuming that if I actually send a nack, I would just close
the connection without sending an ack.

Maybe that should be mentioned in the spec explicitly. I must admit that
I think the name of the message is misleading -- PaymentResponse would
make this clearer.