1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
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
|
