Message-ID: <52E9E787.8080304@borboggle.com>
Date: Thu, 30 Jan 2014 12:47:51 +0700
From: Chuck <chuck+bitcoindev@borboggle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Bitcoin-development] BIP70 message delivery reliability
Precedence: list

I spoke briefly with Peter (sipa). He recommend I forward this post to 
the mailing list for further discussion.

My apologies if this has been discussed before, but I was curious about 
some things re BIP70 message delivery.  In particular, I don't clearly 
see the value of the PaymentACK message.  Allow me to explain...

The current BIP70 workflow designates PaymentACK as the final message in 
a payment exchange. However, it doesn't appear that any mention is made 
of what happens if that delivery fails. I assume that re-delivery is 
left as a detail to the implementation, actually.

For sake of argument, let's assume that PaymentACK is never delivered 
either because of a network outage or a malicious merchant or 
incompatible software between wallets or a bug.  I ask myself: what 
would be necessary for sufficient proof of payment, say, to an arbiter?  
I presume the receipt R=(PaymentRequest,[transactions]) would suffice.  
Am I correct there?

But if the PaymentRequest and broadcasted transactions are enough to 
prove payment, what's the point of the Payment message? The merchant 
never has to verify the Payment message, possibly maliciously ignoring 
it.  In the well-behaved case, I presume the point is to help the 
merchant associate some arbitrary data with the purchase as well as 
provide a refunding address for the customer.  If that's the case, 
couldn't this protocol be slightly improved like so:

Required steps:
1. Customer clicks "pay now"
2. Merchant sends PaymentRequest/PaymentDetails, which should be signed
3. Customer builds a set of transactions and sends a new 
PaymentApprovalRequest message which includes a refund address and the 
unsigned transactions and their associated fully-signed transaction 
hash, the whole message signed with the private key of the refund address.
4. Merchant responds with PaymentApproved message, signing the 
PaymentApprovalRequest message with the same key from step 2.

Optional steps:
5. The customer can send a Payment message, which is only a set of 
signed transactions.
6. The merchant can respond with a PaymentACK message.

In Step 4, the merchant is acknowledging that if the transactions 
provided PaymentApprovalRequest are broadcast, then payment is complete 
and no other steps are required. Steps 5 and 6 aren't required but are 
considered considerate:)

After step 4, all the merchant needs is to do is watch for the 
transactions that were listed in PaymentApprovalRequest.  The 
(PaymentApproved,[signed transactions]) pair is the customer's proof of 
payment and this proof of payment includes a refund address that the 
merchant has agreed to prior to payment, instead of after.  Step 3 & 4 
also allow the merchant to verify transactions, providing an extra layer 
of redundancy.  The merchant will also be able to ack on fees, time lock 
(time sensitive purchases?), sequence numbers, etc.

In Step 3, it's critical the customer sign the message with the private 
key of the refund address, so that the merchant can be confident the 
refund address is correct.

In each step along the way until step 5, if a message delivery fails 
nobody is harmed because the purchase is incomplete.

Thoughts?

Chuck