{"type":"rich","version":"1.0","author_name":"npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","author_url":"https://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-24\n📝 Original message:Andy Schroder\n\nOn 02/23/2015 10:09 AM, Jan Vornberger wrote:\n\u003e Hey!\n\u003e\n\u003e On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:\n\u003e\u003e It's maybe not a bad idea for the wallet to try all payment_url\n\u003e\u003e mechanisms in parallel. Should we add this as a recommendation to\n\u003e\u003e wallets in TBIP75?\n\u003e It doesn't need to be a recommendation I think, but maybe it would be\n\u003e good to mention that a wallet may do that, if it wants.\n\u003e\n\u003e\u003e I actually also happen to be using nfcpy. I am having some\n\u003e\u003e reliability issues as well with it. What exactly are your problems?\n\u003e Aw, interesting. Sometimes transfers seem to start and then not complete\n\u003e in some way and occasionally the NFC dongle is then totally 'stuck' in some\n\u003e way afterwards, that even after restarting the Python script or\n\u003e reloading the driver nothing works anymore. I have to actually unplug\n\u003e the dongle and plug it in again. Obviously not exactly production ready.\n\u003e I had the same problems with the command line tools based on libnfc, so\n\u003e it might be a problem lower down the stack. I'm not sure I have the\n\u003e expertise to troubleshoot that.\n\n\n\nI've had similar issues where the NFC device has to be disconnected and \nreconnected. I've got lots of error checking in my code on the NFC \ndevice, which helps, but still has problems sometimes. I've found if I \nlimit how quickly a new connection can be made, that reduces the \nproblem. Have you tried this?\n\n\n\nWhat command line tool are you using with libnfc?\n\n\n\n\n\n\u003e\n\u003e\u003e I have seen your video before. I guess I'm wondering how your\n\u003e\u003e prototype works with bitpay and bluetooth. Doesn't bitpay sign the\n\u003e\u003e payment request for you with an https based payment_url? If so, how\n\u003e\u003e do you add the bluetooth payment_url while keeping their signature\n\u003e\u003e valid?\n\u003e Good point, I'm currently simply removing the signature, so that I can\n\u003e modify the payment request. I haven't spoken with BitPay yet, but I hope\n\u003e that they will extend their API at some point to set additional\n\u003e payment_urls or provide a Bluetooth MAC and then I can do it properly\n\u003e with signed requests.\n\n\n\nThis sounds weird to me. Why are you even using bitpay at all if you are \nalready going through the effort to remove a signature and change the \nmemo field? Wouldn't it be better to just manage everything yourself?\n\n\n\n\n\u003e\n\u003e\u003e In your video it looks like the phone still has cellular and\n\u003e\u003e wifi reception (it is not offline).\n\u003e You are right, I forgot to actually disable wifi and cellular data when\n\u003e recording the video. But as you know it would work the same way offline.\n\u003e\n\u003e\u003e Regarding the NFC data formats. I would like to clarify that the\n\u003e\u003e wallets are having those events dispatched by the android OS. The\n\u003e\u003e \"URI\" and \"mime type\" events are sent to the application in the same\n\u003e\u003e way as from other sources such as a web browser, e-mail, stand alone\n\u003e\u003e QR code scanner app, etc.. So, I don't think the wallet actually\n\u003e\u003e knows it is receiving the event from NFC. That is one reason why so\n\u003e\u003e many existing wallets happen to support BIP21 payment request via\n\u003e\u003e NFC. Andreas can correct me if I am wrong on these statements. I'm a\n\u003e\u003e little weary sending the \"mime type\" based format over NFC because\n\u003e\u003e of backwards compatibility and because of the long certificate chain\n\u003e\u003e that needs to be transferred. You want that tap to be as robust and\n\u003e\u003e fast as possible. A bluetooth connection can have a retry without\n\u003e\u003e any user interaction.\n\u003e There is a specific NFC intent that you have to list in your Android\n\u003e manifest, but you are right that if you already support BIP21 URIs then\n\u003e it is often fairly easy and quick to also support them via NFC.\n\u003e\n\u003e Whereas the mime type approach means that you necessarily need to be\n\u003e able to actually understand BIP70, which a lot of wallet don't yet. But\n\u003e personally that wouldn't hold me back using the mime type if I feel it's\n\u003e the better experience. Those wallets simply have to fall back on\n\u003e scanning the QR code in the meantime and then get up to speed on their\n\u003e NFC and BIP70 support.\n\u003e\n\u003e I'm still concerned that the fact, that Bluetooth is often disabled, is a\n\u003e problem for the UX. And it's not just a one-time thing as with NFC,\n\u003e which is - in my experience - also often disabled, but then people turn\n\u003e it on and leave it on. But with Bluetooth the Android system is geared\n\u003e much more towards turning it off after use and people have this general\n\u003e idea of 'it uses energy, so I should disable it' and sometimes also\n\u003e 'Bluetooth is insecure and if I leave it on I will get hacked'. So\n\u003e chances are, Bluetooth will be off most of the time, which means\n\u003e everytime you pay the dialog 'Turn on Bluetooth?' will pop up, which\n\u003e isn't exactly streamlined.\n\n\nI'm personally not to annoyed by the enable bluetooth popup. I do know \nwhat you mean about the \"bluetooth is insecure, I should disable it\" \nattitude. I used to have this same concern.\n\n\n\u003e\n\u003e So the advantage of transmitting the whole BIP70 payment request via NFC\n\u003e I see is, that you don't need Bluetooth to get the payment request and\n\u003e for sending the transaction back the wallet can then make an intelligent\n\u003e decision and first try via HTTP and only after that fails, say something\n\u003e like: \"You are currently offline, turn on and transmit via Bluetooth\n\u003e instead?\". Much less confusing to the user, in my opinion.\n\n\nWell, with the multiple r parameters, they should also be able to do \nthis on the payment request too.\n\n\n\u003e\n\u003e Another idea could be to request the permission BLUETOOTH_ADMIN which,\n\u003e as far as I know, allows you to programmatically turn on Bluetooth\n\u003e without user interaction. The wallet could then have a setting somewhere\n\u003e that says 'automatically turn on Bluetooth during payments' which would\n\u003e enable and then disable (if it was off before) Bluetooth during the\n\u003e payment process. That should also be a decent compromise, at the cost of\n\u003e another permission.\n\n\nI'm personally very weary of more permissions. Have you checked out how \nmany unnecessary permissions a lot of bitcoin wallets have? Many of them \nare ridiculous. Although this one may be somewhat warranted, I wouldn't \nencourage it if they can just fall back to cellular if they don't want \nto use bluetooth. If they don't have cellular reception, they can go \nthrough the effort of pressing the enable button that pops up.\n\n\n\n\n\u003e\n\u003e\u003e There is also the \"ack\" memo that I mentioned in reference [2]. I\n\u003e\u003e think we can improve upon this really. Can we make a new status\n\u003e\u003e field or different bluetooth message header? I know Andreas didn't\n\u003e\u003e want to change it because that is how his app already works, but I\n\u003e\u003e don't think the way it is is ideal.\n\u003e I'm fine with doing changes here - I don't think there is all that much\n\u003e stuff out there yet which would break from it. At the moment I'm also\n\u003e modifying BitPay's memo field to contain 'ack', as Andreas' wallet\n\u003e otherwise reports a failure if I transmit the original via Bluetooth. :-)\n\u003e But I was assuming that was temporary anyway (?).\n\u003e\n\u003e Jan\n\u003e\n\u003e\n\u003e\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 555 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150224/10953415/attachment.sig\u003e"}