summaryrefslogtreecommitdiff
path: root/9d/fbb65191039ed484bf9ccb4d74db826c181c3e
blob: 2796c0f58e079e575982ed5c7d15353f52ff6a25 (plain)
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
253
254
255
256
257
258
259
260
261
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <info@AndySchroder.com>) id 1YQ8lg-0006Gf-RS
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 06:14:52 +0000
X-ACL-Warn: 
Received: from uschroder.com ([74.142.93.202])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1YQ8le-000625-KL for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Feb 2015 06:14:52 +0000
Received: from [192.168.253.4] (cpe-74-137-24-201.swo.res.rr.com
	[74.137.24.201])
	by uschroder.com (Postfix) with ESMTPSA id D1CD622BDCE6D;
	Tue, 24 Feb 2015 01:14:44 -0500 (EST)
Message-ID: <54EC16D3.3060103@AndySchroder.com>
Date: Tue, 24 Feb 2015 01:14:43 -0500
From: Andy Schroder <info@AndySchroder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Vornberger <jan@uos.de>
References: <20150222190839.GA18527@odo.localdomain>
	<54EA5A1C.2020701@AndySchroder.com>
	<20150223150937.GA7987@odo.localdomain>
In-Reply-To: <20150223150937.GA7987@odo.localdomain>
X-Enigmail-Version: 1.6
OpenPGP: id=2D44186B;
	url=http://andyschroder.com/static/AndySchroder.asc
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="9WUgQjkEFvRK8EIkagwXHU7eEljU0aXvv"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YQ8le-000625-KL
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
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 Feb 2015 06:14:52 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9WUgQjkEFvRK8EIkagwXHU7eEljU0aXvv
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


Andy Schroder

On 02/23/2015 10:09 AM, Jan Vornberger wrote:
> Hey!
>
> On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:
>> It's maybe not a bad idea for the wallet to try all payment_url
>> mechanisms in parallel. Should we add this as a recommendation to
>> wallets in TBIP75?
> It doesn't need to be a recommendation I think, but maybe it would be
> good to mention that a wallet may do that, if it wants.
>
>> I actually also happen to be using nfcpy. I am having some
>> reliability issues as well with it. What exactly are your problems?
> Aw, interesting. Sometimes transfers seem to start and then not complet=
e
> in some way and occasionally the NFC dongle is then totally 'stuck' in =
some
> way afterwards, that even after restarting the Python script or
> reloading the driver nothing works anymore. I have to actually unplug
> the dongle and plug it in again. Obviously not exactly production ready=
=2E
> I had the same problems with the command line tools based on libnfc, so=

> it might be a problem lower down the stack. I'm not sure I have the
> expertise to troubleshoot that.



I've had similar issues where the NFC device has to be disconnected and=20
reconnected. I've got lots of error checking in my code on the NFC=20
device, which helps, but still has problems sometimes. I've found if I=20
limit how quickly a new connection can be made, that reduces the=20
problem. Have you tried this?



What command line tool are you using with libnfc?





>
>> I have seen your video before. I guess I'm wondering how your
>> prototype works with bitpay and bluetooth. Doesn't bitpay sign the
>> payment request for you with an https based payment_url? If so, how
>> do you add the bluetooth payment_url while keeping their signature
>> valid?
> Good point, I'm currently simply removing the signature, so that I can
> modify the payment request. I haven't spoken with BitPay yet, but I hop=
e
> that they will extend their API at some point to set additional
> payment_urls or provide a Bluetooth MAC and then I can do it properly
> with signed requests.



This sounds weird to me. Why are you even using bitpay at all if you are =

already going through the effort to remove a signature and change the=20
memo field? Wouldn't it be better to just manage everything yourself?




>
>> In your video it looks like the phone still has cellular and
>> wifi reception (it is not offline).
> You are right, I forgot to actually disable wifi and cellular data when=

> recording the video. But as you know it would work the same way offline=
=2E
>
>> Regarding the NFC data formats. I would like to clarify that the
>> wallets are having those events dispatched by the android OS. The
>> "URI" and "mime type" events are sent to the application in the same
>> way as from other sources such as a web browser, e-mail, stand alone
>> QR code scanner app, etc.. So, I don't think the wallet actually
>> knows it is receiving the event from NFC. That is one reason why so
>> many existing wallets happen to support BIP21 payment request via
>> NFC. Andreas can correct me if I am wrong on these statements. I'm a
>> little weary sending the "mime type" based format over NFC because
>> of backwards compatibility and because of the long certificate chain
>> that needs to be transferred. You want that tap to be as robust and
>> fast as possible. A bluetooth connection can have a retry without
>> any user interaction.
> There is a specific NFC intent that you have to list in your Android
> manifest, but you are right that if you already support BIP21 URIs then=

> it is often fairly easy and quick to also support them via NFC.
>
> Whereas the mime type approach means that you necessarily need to be
> able to actually understand BIP70, which a lot of wallet don't yet. But=

> personally that wouldn't hold me back using the mime type if I feel it'=
s
> the better experience. Those wallets simply have to fall back on
> scanning the QR code in the meantime and then get up to speed on their
> NFC and BIP70 support.
>
> I'm still concerned that the fact, that Bluetooth is often disabled, is=
 a
> problem for the UX. And it's not just a one-time thing as with NFC,
> which is - in my experience - also often disabled, but then people turn=

> it on and leave it on. But with Bluetooth the Android system is geared
> much more towards turning it off after use and people have this general=

> idea of 'it uses energy, so I should disable it' and sometimes also
> 'Bluetooth is insecure and if I leave it on I will get hacked'. So
> chances are, Bluetooth will be off most of the time, which means
> everytime you pay the dialog 'Turn on Bluetooth?' will pop up, which
> isn't exactly streamlined.


I'm personally not to annoyed by the enable bluetooth popup. I do know=20
what you mean about the "bluetooth is insecure, I should disable it"=20
attitude. I used to have this same concern.


>
> So the advantage of transmitting the whole BIP70 payment request via NF=
C
> I see is, that you don't need Bluetooth to get the payment request and
> for sending the transaction back the wallet can then make an intelligen=
t
> decision and first try via HTTP and only after that fails, say somethin=
g
> like: "You are currently offline, turn on and transmit via Bluetooth
> instead?". Much less confusing to the user, in my opinion.


Well, with the multiple r parameters, they should also be able to do=20
this on the payment request too.


>
> Another idea could be to request the permission BLUETOOTH_ADMIN which,
> as far as I know, allows you to programmatically turn on Bluetooth
> without user interaction. The wallet could then have a setting somewher=
e
> that says 'automatically turn on Bluetooth during payments' which would=

> enable and then disable (if it was off before) Bluetooth during the
> payment process. That should also be a decent compromise, at the cost o=
f
> another permission.


I'm personally very weary of more permissions. Have you checked out how=20
many unnecessary permissions a lot of bitcoin wallets have? Many of them =

are ridiculous. Although this one may be somewhat warranted, I wouldn't=20
encourage it if they can just fall back to cellular if they don't want=20
to use bluetooth. If they don't have cellular reception, they can go=20
through the effort of pressing the enable button that pops up.




>
>> There is also the "ack" memo that I mentioned in reference [2]. I
>> think we can improve upon this really. Can we make a new status
>> field or different bluetooth message header? I know Andreas didn't
>> want to change it because that is how his app already works, but I
>> don't think the way it is is ideal.
> I'm fine with doing changes here - I don't think there is all that much=

> stuff out there yet which would break from it. At the moment I'm also
> modifying BitPay's memo field to contain 'ack', as Andreas' wallet
> otherwise reports a failure if I transmit the original via Bluetooth. :=
-)
> But I was assuming that was temporary anyway (?).
>
> Jan
>
>
>



--9WUgQjkEFvRK8EIkagwXHU7eEljU0aXvv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJU7BbTAAoJEDT679stRBhr2QoIAJHeZ7hY5o38//qz9pMNryOZ
Mis38OkrU7GHJVPTC7JOR9+c0IvZPk9RRizis+jAQ3MW1b2HDrMT96aSJ2LnP4J9
5nO3QHBGas6UvIUJPj1/BY5WbejuuvLwUp/VB6l8Zy7V3RQEazJ0CNzz35QaXZRP
qkYUKBUdQRHNOrBnfbDykxK9IS5DCe1Ey2SrNv5U2Is9yirDEz8vVOibSSmw5aF3
5DA9o5LvzvNEws7YKerwaNd/QESuUIAhl8w0lLEoTXKRmtMXVepBhQlbq4We+fXM
qnjlwtNjazH4lG2uXBi6giuc0+F9aIer3tjCf3pW1V8eDkLXnwhFNsUAa2Tivcs=
=fEMc
-----END PGP SIGNATURE-----

--9WUgQjkEFvRK8EIkagwXHU7eEljU0aXvv--