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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <idigix@gmail.com>) id 1WzWeH-00026M-Pp
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Jun 2014 19:44:57 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.54 as permitted sender)
client-ip=209.85.213.54; envelope-from=idigix@gmail.com;
helo=mail-yh0-f54.google.com;
Received: from mail-yh0-f54.google.com ([209.85.213.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WzWeF-0006sQ-Nj
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Jun 2014 19:44:57 +0000
Received: by mail-yh0-f54.google.com with SMTP id i57so519672yha.13
for <bitcoin-development@lists.sourceforge.net>;
Tue, 24 Jun 2014 12:44:50 -0700 (PDT)
X-Received: by 10.236.223.229 with SMTP id v95mr4494224yhp.128.1403639090257;
Tue, 24 Jun 2014 12:44:50 -0700 (PDT)
MIME-Version: 1.0
Sender: idigix@gmail.com
Received: by 10.170.151.10 with HTTP; Tue, 24 Jun 2014 12:44:30 -0700 (PDT)
From: Paul Goldstein <paul@realfoot.com>
Date: Tue, 24 Jun 2014 15:44:30 -0400
X-Google-Sender-Auth: p8DOm9lHGqhVWIcHV0tXv_aWNik
Message-ID: <CADE3-jBoZCaRgx=P3AzKGPDCHJW0Z1KLmy_02ke4Jh+RTETqkQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c1ecbe5e25cd04fc9a3152
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
(idigix[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: 1WzWeF-0006sQ-Nj
Subject: [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: Tue, 24 Jun 2014 19:44:58 -0000
--001a11c1ecbe5e25cd04fc9a3152
Content-Type: text/plain; charset=UTF-8
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.
--001a11c1ecbe5e25cd04fc9a3152
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Here's an idea for a BIP 70 extension to let wall=
ets 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). Use=
ful for brick and mortar merchants and mobile 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 cla=
ss=3D"" style=3D"white-space:pre">- </span>Unix timestamp (UTC) after which=
the BillRequest should be considered invalid (wallets may only be monitori=
ng 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">asdf@gmail.com</a>"=
; allowing for a variety of connection options.</font></div>
<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>
--001a11c1ecbe5e25cd04fc9a3152--
|
