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 ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoinfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/bitcoin-development