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
113
114
115
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <christophe.biocca@gmail.com>) id 1WAOa2-00067m-4V
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Feb 2014 18:49:14 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.179 as permitted sender)
client-ip=209.85.192.179;
envelope-from=christophe.biocca@gmail.com;
helo=mail-pd0-f179.google.com;
Received: from mail-pd0-f179.google.com ([209.85.192.179])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WAOa1-0008Rh-4B
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Feb 2014 18:49:14 +0000
Received: by mail-pd0-f179.google.com with SMTP id q10so7225696pdj.38
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Feb 2014 10:49:07 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.68.194.97 with SMTP id hv1mr4662828pbc.162.1391453347208;
Mon, 03 Feb 2014 10:49:07 -0800 (PST)
Received: by 10.68.146.72 with HTTP; Mon, 3 Feb 2014 10:49:07 -0800 (PST)
In-Reply-To: <52EFDB2F.3040604@go-taxi.biz>
References: <52EFDB2F.3040604@go-taxi.biz>
Date: Mon, 3 Feb 2014 13:49:07 -0500
Message-ID: <CANOOu=8oCKVXLHMVAgZyhE1DZ4i==o0dYom9Fe3day6oSQBhRA@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Tim Tuxworth <tim@go-taxi.biz>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.179 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(christophe.biocca[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WAOa1-0008Rh-4B
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: Canceling Payments
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: Mon, 03 Feb 2014 18:49:14 -0000
Over http, the merchant doesn't have the ability to reach out to the
consumer's bitcoin wallet on their own. So sending "Cancel Payment
Request" to the user is impossible.
If the customer doesn't want to send, nothing ever needs to happen. So
sending a "Reject Payment Request" to the merchant is useless.
The unhappy path scenario with Payment Requests (customer paid, but
for whatever reason that payment is no longer valid) can be simply
solved in 1 of 2 ways:
If the merchant realizes the mistake, they can refund the money.
If the customer realizes the problem, they can contact the merchant,
provide the signed request, and ask the merchant to return the funds.
What isn't covered?
On Mon, Feb 3, 2014 at 1:08 PM, Tim Tuxworth <tim@go-taxi.biz> wrote:
> The process described in BIP70 might be ok for a simple "happy path"
> scenario, but what if things don't work so smoothly. I'm not talking
> here about technical issues, but _very common_ business scenarios such as:
>
> e.g. Merchant cancels request before payment is sent, such as when:-
> - the merchant realizes that they charged the wrong amount
> - the merchant realizes that they send the payment request to the wrong
> customer
> ...
>
> e.g. the Merchant or Customer decides to cancel the transaction after
> the payment request is sent because:-
> - the customer decides to pay by some other mechanism like cash or
> credit/debit
> - the customer doesn't have sufficient funds and decides not to purchase
> - the customer changes their mind and decides not to purchase
> ...
>
> It strikes me that a "Cancel Payment Request" message is required
> and a "Reject Payment Request" may also be required (or maybe use the
> same message for both).
>
> Tim Tuxworth
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
