From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8kTx-0001SS-3Z for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 05:48:09 +0000 X-ACL-Warn: Received: from borboggle.com ([69.164.197.78] helo=mail.borboggle.com) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W8kTw-0005Bd-1X for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 05:48:09 +0000 Received: from [192.168.1.72] (unknown [180.183.159.154]) by mail.borboggle.com (Postfix) with ESMTPSA id 532F0FAB0 for ; Thu, 30 Jan 2014 00:59:08 -0500 (EST) Message-ID: <52E9E787.8080304@borboggle.com> Date: Thu, 30 Jan 2014 12:47:51 +0700 From: Chuck 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1W8kTw-0005Bd-1X Subject: [Bitcoin-development] BIP70 message delivery reliability 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: Thu, 30 Jan 2014 05:48:09 -0000 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