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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WAR1x-0004iQ-GF for bitcoin-development@lists.sourceforge.net;
Mon, 03 Feb 2014 21:26:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WAR1u-0004rs-8m
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Feb 2014 21:26:13 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WAR1n-0004UG-Dv for bitcoin-development@lists.sourceforge.net;
Mon, 03 Feb 2014 22:26:03 +0100
Received: from e179068188.adsl.alicedsl.de ([85.179.68.188])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Feb 2014 22:26:03 +0100
Received: from andreas by e179068188.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Feb 2014 22:26:03 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 03 Feb 2014 22:25:53 +0100
Message-ID: <lcp1gk$1d6$1@ger.gmane.org>
References: <5kemthp1y7py3inyyquy78cf.1391459458968@email.android.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: e179068188.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <5kemthp1y7py3inyyquy78cf.1391459458968@email.android.com>
X-Spam-Score: -0.9 (/)
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 [80.91.229.3 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 SPF_PASS SPF: sender matches SPF record
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WAR1u-0004rs-8m
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 21:26:13 -0000
Have a look at my post "Payment Protocol for Face-to-face payments". In
short: I implemented BIP70 using combinations of either QR-code or NFC
plus Bluetooth. You can download a working preview app from:
https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11
On 02/03/2014 09:30 PM, Tim Tuxworth Founder Go-taxi.biz wrote:
> Is BIP70 limited to http only?
>
> What about face to face scenarios, or realtime like ticket sales or
> gambling, and socket and/or bluetooth type connections?
>
> Tim Tuxworth
> Founder Go-Taxi.biz
>
>
> -------- Original message --------
> From: Christophe Biocca
> Date:2014/02/03 10:49 AM (GMT-08:00)
> To: Tim Tuxworth
> Cc: bitcoin-development@lists.sourceforge.net
> Subject: Re: [Bitcoin-development] BIP70: Canceling Payments
>
> 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
>
>
> ------------------------------------------------------------------------------
> 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
>
|
