diff options
| author | Chuck <chuck+bitcoindev@borboggle.com> | 2014-01-30 12:47:51 +0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-01-30 05:48:09 +0000 |
| commit | 580fd4bd4f84d714474e69515d721a9490e233de (patch) | |
| tree | 14a05ee497829b227022b7b35eacfda936290d89 | |
| parent | 78320038581eb606816e5a4f0a6b7bc7ce39ee8a (diff) | |
| download | pi-bitcoindev-580fd4bd4f84d714474e69515d721a9490e233de.tar.gz pi-bitcoindev-580fd4bd4f84d714474e69515d721a9490e233de.zip | |
[Bitcoin-development] BIP70 message delivery reliability
| -rw-r--r-- | 12/e1abe8afe75500efb77572bc408cc1a1034728 | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/12/e1abe8afe75500efb77572bc408cc1a1034728 b/12/e1abe8afe75500efb77572bc408cc1a1034728 new file mode 100644 index 000000000..6bb066f4f --- /dev/null +++ b/12/e1abe8afe75500efb77572bc408cc1a1034728 @@ -0,0 +1,112 @@ +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 <chuck+bitcoindev@borboggle.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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 <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 +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 + + |