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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WzlIu-0007CQ-Pp
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 11:23:53 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.170 as permitted sender)
client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f170.google.com;
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WzlIt-0004C3-1x
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 11:23:52 +0000
Received: by mail-ob0-f170.google.com with SMTP id uz6so1913346obc.29
for <bitcoin-development@lists.sourceforge.net>;
Wed, 25 Jun 2014 04:23:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.114.229 with SMTP id jj5mr7202252obb.53.1403695425538;
Wed, 25 Jun 2014 04:23:45 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Wed, 25 Jun 2014 04:23:45 -0700 (PDT)
In-Reply-To: <CADE3-jBoZCaRgx=P3AzKGPDCHJW0Z1KLmy_02ke4Jh+RTETqkQ@mail.gmail.com>
References: <CADE3-jBoZCaRgx=P3AzKGPDCHJW0Z1KLmy_02ke4Jh+RTETqkQ@mail.gmail.com>
Date: Wed, 25 Jun 2014 13:23:45 +0200
X-Google-Sender-Auth: PdwEBpUxIPXkmCjqBoD7Mm3-bGk
Message-ID: <CANEZrP3_pKzuS6mWL4TNAQcEcz_6wwzUX8LPtmdv2XUJSvDKuw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Paul Goldstein <paul@realfoot.com>
Content-Type: multipart/alternative; boundary=001a11c2f64436541604fca74fef
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1WzlIt-0004C3-1x
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bill Request Message - (another) Proposed
BIP 70 extension
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: Wed, 25 Jun 2014 11:23:53 -0000
--001a11c2f64436541604fca74fef
Content-Type: text/plain; charset=UTF-8
I'm not convinced this inversion is really a problem, but as this is quite
a complex proposal (e.g. new barcode types) the best way to move it forward
at this stage is to implement it in some existing wallets.
FWIW NFC is a lot more common than you might think. For the drive-thru case
you could also consider using wifi hotspots with a special name or
Bluetooth LE tags. So I suspect before trying to write a specification it'd
be better to explore different technologies and see what works best in
practice.
On Tue, Jun 24, 2014 at 9:44 PM, Paul Goldstein <paul@realfoot.com> wrote:
> Here's an idea for a BIP 70 extension to let wallets be scanned by
> merchant bar code readers to start off a payment request flow instead of
> the other way around (wallet scanning the merchant QR). Useful for brick
> and mortar merchants and mobile wallet apps.
>
>
> Motivation:
> A mechanism is needed for mobile wallets to request a bill, so that a
> payment protocol flow can be initiated. Current mechanisms for initiating
> BIP70 payment flows generally require wallets to either scan a merchant
> barcode (not optimal, see below), or click on a specially formatted url
> link (only suitable while browsing and purchasing on a merchant website).
>
> Successful non-bitcoin mobile wallet apps to date (a popular coffee shop
> app comes to mind) allow for the wallet app to be scanned by the merchant
> and not the other way around (as is commonly done in bitcoin wallets
> today). For broad bitcoin adoption we need a mechanism for wallets to be
> scanned by merchant bar code readers at brick and mortar shops. This will
> also greatly ease checkouts at drive throughs and allows merchants to
> leverage existing hardware (barcode readers).
>
> Other technologies like NFC may obviate the need for this extension,
> however, those technologies remain somewhat uncommon and may not be
> suitable for smaller wearables hitting the market.
>
> message BillRequest {
> required uint64 time = 1;
> optional uint64 expires = 2;
> required string bill_request_uri = 3;
> }
>
>
> time - Unix timestamp (seconds since 1-Jan-1970 UTC) when the BillRequest
> was created.
> expires - Unix timestamp (UTC) after which the BillRequest should be
> considered invalid (wallets may only be monitoring for messages for a short
> time).
> bill_req_addr - Typically a URL where a BIP70 payment request can be sent
> that is being monitored by the wallet. However this could also support URIs
> like "sms:860-555-1212" or "mailto:asdf@gmail.com" allowing for a variety
> of connection options.
>
> Recommendations: it is recommended that wallet apps display a non-QR
> barcode like a PDF417 barcode to initiate the Bill Request flow. This will
> avoid confusion with existing QR code usage in wallet apps.
>
> --------
> Paul G.
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a11c2f64436541604fca74fef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm not convinced this inversion is really a problem, =
but as this is quite a complex proposal (e.g. new barcode types) the best w=
ay to move it forward at this stage is to implement it in some existing wal=
lets.<div>
<br></div><div>FWIW NFC is a lot more common than you might think. For the =
drive-thru case you could also consider using wifi hotspots with a special =
name or Bluetooth LE tags. So I suspect before trying to write a specificat=
ion it'd be better to explore different technologies and see what works=
best in practice.</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Jun 24, 2014 at 9:44 PM, Paul Goldstein <span dir=3D"ltr">&=
lt;<a href=3D"mailto:paul@realfoot.com" target=3D"_blank">paul@realfoot.com=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Here's an idea for=
a BIP 70 extension to let wallets be scanned by merchant bar code readers =
to start off a payment request flow instead of the other way around (wallet=
scanning the merchant QR). Useful for brick and mortar merchants and mobil=
e wallet apps.</div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace">Motivation:</font></div><div><font face=3D"courier new, monosp=
ace">A mechanism is needed for mobile wallets to request a bill, so that a =
payment protocol flow can be initiated. Current mechanisms for initiating B=
IP70 payment flows generally require wallets to either scan a merchant barc=
ode (not optimal, see below), or click on a specially formatted url link (o=
nly suitable while browsing and purchasing on a merchant website).=C2=A0</f=
ont></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">Successful non-bitcoin mobile wallet apps to da=
te (a popular coffee shop app comes to mind) allow for the wallet app to be=
scanned by the merchant and not the other way around (as is commonly done =
in bitcoin wallets today). For broad bitcoin adoption we need a mechanism f=
or wallets to be scanned by merchant bar code readers at brick and mortar s=
hops. This will also greatly ease checkouts at drive throughs and allows me=
rchants to leverage existing hardware (barcode readers).=C2=A0</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">Other technologies like NFC may obviate the nee=
d for this extension, however, those technologies remain somewhat uncommon =
and may not be suitable for smaller wearables hitting the market.</font></d=
iv>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">message BillRequest {</font></div><div><font fa=
ce=3D"courier new, monospace">=C2=A0required uint64 time =3D 1;</font></div=
><div><font face=3D"courier new, monospace">=C2=A0optional uint64 expires =
=3D 2;</font></div>
<div><font face=3D"courier new, monospace">=C2=A0required string bill_reque=
st_uri =3D 3;</font></div><div><font face=3D"courier new, monospace">}=C2=
=A0</font></div><div><font face=3D"courier new, monospace"><br></font></div=
><div><font face=3D"courier new, monospace"><br>
</font></div><div><font face=3D"courier new, monospace">time -=C2=A0Unix ti=
mestamp (seconds since 1-Jan-1970 UTC) when the BillRequest was created.</f=
ont></div><div><font face=3D"courier new, monospace">expires=C2=A0<span sty=
le=3D"white-space:pre-wrap">- </span>Unix timestamp (UTC) after which the B=
illRequest should be considered invalid (wallets may only be monitoring for=
messages for a short time).</font></div>
<div><font face=3D"courier new, monospace">bill_req_addr - Typically a URL =
where a BIP70 payment request can be sent that is being monitored by the wa=
llet. However this could also support URIs like "sms:860-555-1212"=
; or "mailto:<a href=3D"mailto:asdf@gmail.com" target=3D"_blank">asdf@=
gmail.com</a>" allowing for a variety of connection options.</font></d=
iv>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">Recommendations: it is recommended that wallet =
apps display a non-QR barcode like a PDF417 barcode to initiate the Bill Re=
quest flow. This will avoid confusion with existing QR code usage in wallet=
apps.</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">--------</font></div><div><font face=3D"arial, =
helvetica, sans-serif">Paul G.</font></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Open source business process management suite built on Java and Eclipse<br>
Turn processes into business applications with Bonita BPM Community Edition=
<br>
Quickly connect people, data, and systems into organized workflows<br>
Winner of BOSSIE, CODIE, OW2 and Gartner awards<br>
<a href=3D"http://p.sf.net/sfu/Bonitasoft" target=3D"_blank">http://p.sf.ne=
t/sfu/Bonitasoft</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--001a11c2f64436541604fca74fef--
|
