path: root/9d/fbb65191039ed484bf9ccb4d74db826c181c3e

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--