From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--