public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chuck <chuck+bitcoindev@borboggle.com>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] BIP70 message delivery reliability
Date: Thu, 30 Jan 2014 12:47:51 +0700	[thread overview]
Message-ID: <52E9E787.8080304@borboggle.com> (raw)

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



             reply	other threads:[~2014-01-30  5:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-30  5:47 Chuck [this message]
2014-01-30 10:49 ` [Bitcoin-development] BIP70 message delivery reliability Mike Hearn
2014-01-30 11:15   ` Chuck
2014-01-30 11:31     ` Mike Hearn
2014-01-30 11:42       ` Chuck
2014-01-30 11:46     ` Pieter Wuille
2014-01-30 11:59       ` Mike Hearn
2014-01-30 12:02         ` Pieter Wuille
2014-01-30 12:03           ` Chuck
2014-01-30 12:20             ` Roy Badami
2014-01-30 12:38             ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52E9E787.8080304@borboggle.com \
    --to=chuck+bitcoindev@borboggle.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox