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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alexy.kot.all@gmail.com>) id 1WQSdO-0000Ps-5m
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 02:23:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.176 as permitted sender)
client-ip=209.85.220.176; envelope-from=alexy.kot.all@gmail.com;
helo=mail-vc0-f176.google.com;
Received: from mail-vc0-f176.google.com ([209.85.220.176])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WQSdN-0008TC-1J
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 02:23:06 +0000
Received: by mail-vc0-f176.google.com with SMTP id lc6so219011vcb.21
for <bitcoin-development@lists.sourceforge.net>;
Wed, 19 Mar 2014 19:22:59 -0700 (PDT)
X-Received: by 10.52.65.165 with SMTP id y5mr945272vds.51.1395282179497; Wed,
19 Mar 2014 19:22:59 -0700 (PDT)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.59.0.38 with HTTP; Wed, 19 Mar 2014 19:22:19 -0700 (PDT)
In-Reply-To: <CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
References: <lc5hmg$1jh$1@ger.gmane.org> <leuunm$tjk$1@ger.gmane.org>
<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
From: Alex Kotenko <alexykot@gmail.com>
Date: Thu, 20 Mar 2014 02:22:19 +0000
X-Google-Sender-Auth: gEheqTpSLqEf5ZJ04GdXvc8UzV8
Message-ID: <CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=20cf307f3256aba6a204f50072a6
X-Spam-Score: -0.3 (/)
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
(alexy.kot.all[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.3 HTML_FONT_FACE_BAD BODY: HTML font face is not a word
-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: 1WQSdN-0008TC-1J
Cc: Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face 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: Thu, 20 Mar 2014 02:23:06 -0000
--20cf307f3256aba6a204f50072a6
Content-Type: text/plain; charset=UTF-8
Hi Andreas
I'm implementing support for BIP70 in my POS at the moment, and I've just
realized that with options you're proposing usecase I'm looking for is not
covered.
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to support BIP70. And also I want to avoid
using external servers, the concept of my POS is that everything is
happening between just payer's phone and payee's POS device. This means
that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
You're also offering an option to include Base43 encoded PR body right
inside the Bitcoin URI, but in a way that is not backwards compatible with
BIP21.
In the end this all means that there is no way for me to at the same time
keep backwards compatibility with all wallets not supporting NFC and BIP70
(all other wallets right now), and keep things inside POS without need for
external servers.
I understand your intention behind base43 encoding and noncompatible URI -
you want to make most possible use of QR codes. But I wonder - did you
compare this base43 to base64 encoded request in a binary QR code format?
How much do we actually win in total bytes capacity at a price of
noncompatibility and increased complexity?
And also maybe we can extend BIP72 to include encoded payment request in
the URL directly in a backwards compatible way?
Best regards,
Alex Kotenko
2014-03-02 11:50 GMT+00:00 Mike Hearn <mike@plan99.net>:
> Thanks Andreas.
>
> For BIP standardisation, I think the VIEW intent seems like an obvious
> one. Bluetooth support probably should come later if/when we put
> encryption/auth on the RFCOMM link (probably SSL).
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--20cf307f3256aba6a204f50072a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier =
new,monospace;color:#003300">Hi Andreas</div><div class=3D"gmail_default" s=
tyle=3D"font-family:courier new,monospace;color:#003300"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:courier new,monospace;color:#0033=
00">
<br></div><div class=3D"gmail_default" style=3D"font-family:courier new,mon=
ospace;color:#003300">
I'm implementing support for BIP70 in my POS at the moment, and I'v=
e just realized that with options you're proposing usecase I'm look=
ing for is not covered.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:courier new,monospace;color:#003300">
<br></div><div class=3D"gmail_default" style=3D"font-family:courier new,mon=
ospace;color:#003300">Right now, before BIP70, I'm sending BIP21 URI vi=
a NFC or QR code, and I need to still be able to use it for backwards compa=
tibility. But at the same time I want to be able to support BIP70. And also=
I want to avoid using external servers, the concept of my POS is that ever=
ything is happening between just payer's phone and payee's POS devi=
ce. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable f=
or me.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace;color:#003300">You're also offering an option to inc=
lude Base43 encoded PR body right inside the Bitcoin URI, but in a way that=
is not backwards compatible with BIP21.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace;color:#003300">In the end this all means that there is n=
o way for me to at the same time keep backwards compatibility with all wall=
ets not supporting NFC and BIP70 (all other wallets right now), and keep th=
ings inside POS without need for external servers.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace;color:#003300">I understand your intention behind base43=
encoding and noncompatible URI - you want to make most possible use of QR =
codes. But I wonder - did you compare this base43 to base64 encoded request=
in a binary QR code format? How much do we actually win in total bytes cap=
acity at a price of noncompatibility and increased complexity?</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace;color:#003300">And also maybe we can extend BIP72 to inc=
lude encoded payment request in the URL directly in a backwards compatible =
way?</div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300"><br></div><div class=3D"gmail_extra"><br clear=3D"all">
<div><div dir=3D"ltr"><span style=3D"color:rgb(0,51,0);font-family:'cou=
rier new',monospace">Best regards,=C2=A0</span><div>
<div><div style=3D"text-align:left"><font color=3D"#003300" face=3D"'co=
urier new', monospace" style=3D"text-align:-webkit-auto">Alex Kotenko</=
font></div></div></div></div></div>
<br><br><div class=3D"gmail_quote">2014-03-02 11:50 GMT+00:00 Mike Hearn <s=
pan dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mi=
ke@plan99.net</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">Thanks Andreas.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">For BIP standardisati=
on, I think the VIEW intent seems like an obvious one. Bluetooth support pr=
obably should come later if/when we put encryption/auth on the RFCOMM link =
(probably SSL).</div>
</div>
<br>-----------------------------------------------------------------------=
-------<br>
Flow-based real-time traffic analytics software. Cisco certified tool.<br>
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer<br>
Customize your own dashboards, set traffic alerts and generate reports.<br>
Network behavioral analysis & security monitoring. All-in-one tool.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D126839071&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D126839071&iu=3D/4140/ostg.clktrk</a><br>__________________=
_____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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></div>
--20cf307f3256aba6a204f50072a6--
|
