diff options
| author | Andy Schroder <info@AndySchroder.com> | 2015-02-24 01:14:43 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-02-24 06:14:52 +0000 |
| commit | c121c4c30a7595e634382977a66896b071572b40 (patch) | |
| tree | 143453e090b5e56a3563702c6a1cc94837904ae7 | |
| parent | c94b83c794dbb5a417a2b8dfde4e4f2cb1990824 (diff) | |
| download | pi-bitcoindev-c121c4c30a7595e634382977a66896b071572b40.tar.gz pi-bitcoindev-c121c4c30a7595e634382977a66896b071572b40.zip | |
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
| -rw-r--r-- | 9d/fbb65191039ed484bf9ccb4d74db826c181c3e | 261 |
1 files changed, 261 insertions, 0 deletions
diff --git a/9d/fbb65191039ed484bf9ccb4d74db826c181c3e b/9d/fbb65191039ed484bf9ccb4d74db826c181c3e new file mode 100644 index 000000000..2796c0f58 --- /dev/null +++ b/9d/fbb65191039ed484bf9ccb4d74db826c181c3e @@ -0,0 +1,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-- + + |