Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?
Andy Schroder On 06/10/2015 03:20 PM, Peter Todd wrote: On Wed, Jun 10, 2015 at 03:12:02PM -0400, Andy Schroder wrote: Andy Schroder On 06/10/2015 03:03 PM, Peter Todd wrote: 4. Seems like digital signatures are always broken on messages because the list server slightly modifies them (?), so my e-mail client doesn't verify them all. What type of digital signatures specifically? What email client? I think they are usually PGP/MIME signatures that are not working right. If you'll notice from my e-mail headers: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 X-Enigmail-Version: 1.6 It might be that Thunderbird doesn't properly handle messages with both signed and unsigned content. I use mutt myself, which handles it just fine. (the sigs on your emails verify just fine for instance) It's possible that the enigmail extension is not working right, but I was under the impression that it is just feeding data to gpg and then receiving the response back. It's possible that your e-mail you just checked was not sent through mailman since I also replied directly to you explicitly (in which case the message has not been modified) and you probably have the setting in the mailing list set to not send duplicate messages if you are an explicit TO. I just deleted all explicit TOs for this message, so everyone should be receiving it through the mailing list and not directly. Is the signature still valid for you now? I think enigmail can handle messages with some signed and unsigned content, and maybe PGP/MIME inherently does not support this and a mailing list re-writing parts of messages is an expected action? If this message re-writing is an expected action and I'm correct that PGP/MIME does not support partially signed content, then maybe it is just a recommendation for this mailing list to not use PGP/MIME for messages sent to the list? Can anyone else confirm? signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?
Hello, Thanks for testing this clarifying things about PGP/MIME and I apologize for wasting your time with it. It looks like a SPAM filtering service I use is re-writing some parts of some plain text messages with some special/alternate encoding characters (not sure what it really is). Anyway, if I manually export/import a message from gmane (bypassing my e-mail SPAM filter), thunderbird/enigmail is not having problems verifying signatures. I guess I never realized this before because all other signed messages I normally receive are encrypted and the SPAM filter does not mess with non plain text data. Andy Schroder On 06/10/2015 03:43 PM, Peter Todd wrote: On Wed, Jun 10, 2015 at 03:36:42PM -0400, Andy Schroder wrote: It's possible that the enigmail extension is not working right, but I was under the impression that it is just feeding data to gpg and then receiving the response back. It's possible that your e-mail you just checked was not sent through mailman since I also replied directly to you explicitly (in which case the message has not been modified) and you probably have the setting in the mailing list set to not send duplicate messages if you are an explicit TO. I just deleted all explicit TOs for this message, so everyone should be receiving it through the mailing list and not directly. Is the signature still valid for you now? I think enigmail can handle It has perfectly valid signatures, as do your earlier messages to the list. messages with some signed and unsigned content, and maybe PGP/MIME inherently does not support this and a mailing list re-writing parts of messages is an expected action? If this message re-writing is an expected action and I'm correct that PGP/MIME does not support partially signed content, then maybe it is just a recommendation for this mailing list to not use PGP/MIME for messages sent to the list? PGP/MIME definitely does support partially signed content. signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Manually quoting a reply from Andreas that was sent privately while the e-mail list was 2 days delayed delivering messages On 02/25/2015 02:45 AM, Andreas Schildbach wrote: Bear in mind that the bt: scheme is already in use by ~700.000 installations. If we change the protocol except just wrapping a secure layer, we should change the scheme to for example bs: (Bluetooth secure). This bs: is not a bad idea. Is bts: any better/clearer than bs:? That said, I don't like the idea to fold the resource name and the session key into one. Resource names can be shared by multiple protocols, for example a merchant may publish payment requests under bt:mac/r1*and* https://domain/r1. If you want to save space and don't need resources, you can always just use bt:mac and a default resource (bt:mac/) is assumed. I'm going to agree with Andreas on this. The other thing is we are making the resource name derived from the public key, so we are not even directly sending the resource name. Have we decided on the use (or non-use) of a DHKE (or similar) protocol like Mike suggested? We are planning to send a unique public key of the payee via NFC. See other e-mails now that the e-mail list finally forwarded them through the other day. Now for Eric's e-mail... More below. On 02/24/2015 09:09 PM, Eric Voskuil wrote: On 02/24/2015 02:50 PM, Andy Schroder wrote: We can change resource to Session ID if you want. I think the URL scheme should be: bitcoin:[address]?r=bt:macs=PublicKey This is a question of proper URL semantics, as applied to the bt scheme. From rfc3986 [Uniform Resource Identifier (URI): Generic Syntax]: The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). ... The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). The query component is indicated by the first question mark (?) character and terminated by a number sign (#) character or by the end of the URI. https://tools.ietf.org/html/rfc3986#section-3.3 The question therefore is whether key is (1) relative to the path (hierarchical) or (2) independent of the path and instead relative to the scheme and naming authority. The bt scheme does not include a naming authority, and as such the question is simply whether key is relative to bt or relative to the path, which is mac. Quite clearly key is valid only in the context of mac, not relevant to all macs. As such one must conclude that the proper form is: bt:mac/key See my comments above. But when connecting to the mac, the client indicates the SessionID in the header, and as you say, SessionID is derived in some way from PublicKey. Yes. This is a slightly different format than both of your suggestions below, but seems to make more sense based on what you said in your entire message. The other thing is it can be used with more protocols without taking up more space in the URL. However, by loosing the h= parameter, I think we are now loosing some benefit it brought to https based connections if the customer doesn't want to use bluetooth. Right? I don't believe that the BIP-70 protocol over https has any need for the parameter. It was only useful because the NFC/BT session wasn't secured. So I don't think anything is lost. This may be true. Andreas, do you agree? I feel like there was something in your app where it did not currently compare the domain name to domain name the digital signature in the payment request used though. Maybe this was only for bluetooth though? However, can we trust DNS though? Seems like it is not too hard to get an alternate signed certificate for a domain name, and if you can serve false DNS and/or change TCP/IP routing, then your secure link can break down? Also, you talk about a new public key (and session ID) for each tap. I guess I'm wondering about this though. If the public key is compromised on the first tap, isn't their payment request already compromised? Yes, but that is not the problem that non-reuse is designed to resolve. Reuse of the public key creates a forward secrecy problem. If 1000 sessions are recorded, and later the private key associated with the reused public key is compromized, all of the sessions are retroactively compromised. Another problem is persistent impersonation. If the one associated private key is compromised, and nobody knows it, the attacker can not only monitor all transactions but can selectively steal payments (if they aren't signed and verified). This is BTW also a good reason to not use HD generation of these session keys. Another problem is that any payer can use the well-known public key to obtain payment
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Hello, I think were talking about a lot of the same things. There is one key piece of information that I was not thinking about until you made it clear. Why the payee needs to identify the payer. In my fuel pump application, they really don't, so I wasn't thinking closely about these other situations. With my fuel pump, it won't even let you do anything until you sign a transaction and submit it. So, the payment request contains no personal information, it's just a request for payment, and not for anything specific. It doesn't know or care what you are going to buy until you make a prepayment, because there is no use in trying to start doing business without a signed transaction. This approach minimizes risk because once you dispense a fuel, or anything else, it's not like you can easily give it back if you happened to not have any funds. It also makes it a higher chance for a confirmation before the customer leaves. Other transactions have similar post payment traditions, like a restaurant (not fast food), where the seller doesn't know if you actually have enough money until you've already consumed the food, but this work flow seems to be a culturally driven one rather than risk driven. In the discussion about an https website, there are many websites where no login or authentication by the client required to have a private connection. With a shopping website though, the customer can identify themselves without logging in by saying (in band) what they are intending to buy after the private connection has been established. At a cash register in person the items being purchased have no tie to the customer. The items being purchased were communicated to the seller out of band (in real life) and insecurely to establish that link. You are trying to make a tie between that list of items and the buyer separately, and that is why some unique identifier needs to be transmitted via NFC. Stepping a bit back: I guess I'm wondering if it would be useful to encourage an opposite work flow where a micro payment channel is setup for most purchases. For example, if I go to the grocery store, it usually takes a minute or so to check out. If I immediately tap and open up a payment channel with the store when I start checkout, rather than finish, there can be more network propagation of that transaction while they are scanning all the items. They'll see the channel is open and start adding all the items I want to buy to that micro payment channel. I'm identified because I made a payment, not because I've transmitted a unique resource or used a unique public key to encrypt communication. A payment terminal would not allow for new payment channels to be open until the currently active one is closed. If I don't have enough funds left in the payment channel, they just stop scanning items. There may be some additional privacy implications of setting up micro payment channels all the time for everyday purchases. It also may not work for every sales case, so we may still need some way to authenticate the payer with a unique identifier. So, maybe we don't want to do this, but it is just a thought to consider. So, unless someone thinks what I am proposing in my previous paragraph has any potential (as a complete solution, not a complement to solutions), the plan is the following: * Get rid of the h= parameter * Add a s= parameter that uses a unique public key for each session. This public key identifies the payee to the payer and payer to the payee. * Use a base58 encoding to save space and reduce the character set slightly. * Get rid of the resource? If a terminal is accepting payment from multiple customers simultaneously, it should be smart enough to distinguish between customers based on the public key they are encrypting the data with. Is this approach feasible? * When you said a new public key for each tap, do you see that as every single tap, or do you consider multiple taps from the same customer the same tap? Andy Schroder On 02/24/2015 06:28 AM, Eric Voskuil wrote: On 02/23/2015 09:53 PM, Andy Schroder wrote: I was saying provide a public key via NFC (or a public key fingerprint and then send the full public key over bluetooth). Instead of providing a new public key on each tap, why can't the payee just stop accepting connections from new parties on that resource after a session key has been received from the first person? Because the presumption was that there was not an additional secret in the URI. If the public key is reused then anyone can spoof a payer and obtain payment requests. Adding a secret to the URI can resolve this, as long as it is encrypted with the public key before being transmitted back to BT. Otherwise the secret can be intercepted and replayed to the terminal, encrypted with the well-known public key. So if you want to treat the resource as a secret this would work. However the resource was designed
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
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 complete 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. 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 reconnected. I've got lots of error checking in my code on the NFC device, which helps, but still has problems sometimes. I've found if I limit how quickly a new connection can be made, that reduces the 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 hope 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 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. 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 what you mean about the bluetooth is insecure, I should disable it attitude. I used to have this same concern. So the advantage of transmitting the whole BIP70 payment request via NFC 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 intelligent decision and first try via HTTP and only
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
We can change resource to Session ID if you want. I think the URL scheme should be: bitcoin:[address]?r=bt:macs=PublicKey But when connecting to the mac, the client indicates the SessionID in the header, and as you say, SessionID is derived in some way from PublicKey. This is a slightly different format than both of your suggestions below, but seems to make more sense based on what you said in your entire message. The other thing is it can be used with more protocols without taking up more space in the URL. However, by loosing the h= parameter, I think we are now loosing some benefit it brought to https based connections if the customer doesn't want to use bluetooth. Right? Also, you talk about a new public key (and session ID) for each tap. I guess I'm wondering about this though. If the public key is compromised on the first tap, isn't their payment request already compromised? Since we are securing everything, can we change the message header format from what Schildbach's bitcoin wallet implements to something more consistent? Maybe we can create a new UUID for this secure service so Schildbach's bitcoin wallet can still maintain backwards compatibility. Andy Schroder On 02/24/2015 05:14 PM, Eric Voskuil wrote: * Add a s= parameter that uses a unique public key for each session. This public key identifies the payee to the payer and payer to the payee. This would be the simple model, which just tacks on another parameter to the bitcoin URL: bitcoin:[address]?bt=macs=key But we should also look at the more flexible r# approach from your existing TBIPs, which would yield: bitcoin:[address]?r=bt:mac/key and incorporate the payment_url list. * Use a base58 encoding to save space and reduce the character set slightly. :) * Get rid of the resource? If a terminal is accepting payment from multiple customers simultaneously, it should be smart enough to distinguish between customers based on the public key they are encrypting the data with. Is this approach feasible? Yes, it is not necessary on the URL. But an id is useful in helping the BT terminal identify the session without having to try all of its outstanding keys until it finds one that works. I proposed that the resource name (session id may be a better name) be deterministically derived from the session key. Given the design change to pass an EC public key it would need to be derived from that key (not from the session key because the receiver would not have a copy before decrypting the first BT message). So any function on the public key that reduces it to a smaller length, fixed width should be fine. Hashing it first may be better as is prevents disclosure of any bits of the public key, which should be treated as a secret during the session. * When you said a new public key for each tap, do you see that as every single tap, or do you consider multiple taps from the same customer the same tap? Yes, since there would be no other way to distinguish between customers in some scenarios and this is the safest approach. We certainly won't run out of numbers, and unused sessions can be discarded based on any number of criteria, including discarding all but the most recent. That may may be sufficient for your vending machines given there's little if any call for parallelism. e signature.asc Description: OpenPGP digital signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Hello Jan, Regarding a few of your questions: Andreas and I had a number of private discussions regarding the payment_url parameter. I had suggested a additional_payment_urls repeated parameter, but he didn't seem to like that idea and I personally am indifferent, so that is why we decided to just change payment_url to a repeated field. The spec is simpler without the additional_payment_urls, but the wallets have to be a little bit smarter finding the right url they want to use in the list. 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? I had heard from Andreas a few weeks ago that the multiple r parameters was not yet implemented. Maybe your interest can motivate him to do so! I actually also happen to be using nfcpy. I am having some reliability issues as well with it. What exactly are your problems? 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? In your video it looks like the phone still has cellular and wifi reception (it is not offline). You mention workflow options 1,2,3. You forgot to mention that options 1,2 are not backwards compatible with older wallets. 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. I don't really understand why Mike Hearn has the objections to the h parameter. It seems like you should already be ready to produce the BIP70 payment request at the time when the URI is generated. I'd also like to clarify that the h parameter is for more than just unsigned payment requests. You can have a signed payment request with the wrong signer. There is way to much brainpower required to verify that the signer is actually the merchant you are doing business with. Just think how many times you shop at a store that you don't even know the name of. Also, the store may contract their payment processing out to another party, or they may have multiple store names but use the same payment processing system for all their stores, and the parent company has a different name. It's good to have both the h parameter AND the signed payment request. I don't really like the Airbitz proposal. Figuring out if your selecting is the right one is a real nuisance. The idea is neat in a few applications, but I just don't think it is going to work for people as the most efficient and trouble free option day to day. I realize they are probably doing it to work with Apple's limited functionality phones (and BLE is a new buzz word). However, I don't think we should base bitcoin around what Apple wants us to do. They've already had their war on bitcoin. They are going to do whatever they can to protect their NFC based payment system. We need to make their platform the the less desirable one if they are going to play the game that way. If that means an Airbitz like proposal is implemented as a fallback, maybe that is fine and POS systems need to support both, but I just don't think we should limit what we can do because of Apple's products capabilities. 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'd like to see some discussion too about securing the bluetooth connection. Right now it is possible for an eavesdropper to monitor the data transferred. I'd personally like to see if wrapping the current connection with SSL works or if we can run https over a bluetooth socket. There was some criticism of this, but I don't think it has been tested to know if it is really a problem or not. If we just run https over bluetooth, then a lot of my concerns about the message header inconsistencies will go away and the connection will also be secure. We don't have to reinvent anything. Andy Schroder On 02/22/2015 02
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Andy Schroder On 02/22/2015 06:06 PM, Eric Voskuil wrote: On 02/22/2015 02:37 PM, Andy Schroder wrote: I'd like to see some discussion too about securing the bluetooth connection. Right now it is possible for an eavesdropper to monitor the data transferred. Yes, this should be a prerequisite issue to all others. I'd personally like to see if wrapping the current connection with SSL works or if we can run https over a bluetooth socket. There is no reason to add this significant complexity. The purpose of SSL/TLS is to establish privacy over a *public* channel. But to do so requires verification by the user of the merchant's public certificate. Once we rely on the channel being *private*, the entire SSL process is unnecessary. I guess we need to decide whether we want to consider NFC communication private or not. I don't know that I think it can be. An eavesdropper can place a tiny snooping device near and read the communication. If it is just passive, then the merchant/operator won't realize it's there. So, I don't know if I like your idea (mentioned in your other reply) of putting the session key in the URL is a good idea? Presumably we would not want to require PKI for privacy, since that's a bit of a contradiction. But if one wants to do this NFC is not required, since the private session can be established over the public (Bluetooth) network. There was some criticism of this, but I don't think it has been tested to know if it is really a problem or not. If we just run https over bluetooth, then a lot of my concerns about the message header inconsistencies will go away and the connection will also be secure. We don't have to reinvent anything. Andy Schroder On 02/22/2015 02:08 PM, Jan Vornberger wrote: Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go with the combination of NFC and Bluetooth: Doing everything via NFC is an interesting option to keep things simple, but the issue is, that one usually can't maintain the connection while the user confirms the transaction (as they take the device back to press a button or maybe enter a PIN). So there are three options: 1. Do a double tap: User taps, takes the device back, confirms, then taps again to transmit the transaction. (I think Google Wallet does something like this.) 2. Confirm beforehand: User confirms, then taps and everything can happen in one go. The disadvantage is, that you confirm the transaction before you have seen the details. (I believe Google Wallet can also work this way.) 3. Tap the phone, then establish a Bluetooth connection which allows you to do all necessary communication even if the user takes the device back. I feel that option 3 is the nicest UX, so that is what I am focusing on right now, but there are pros and cons to all options. One disadvantage of option 3 in practice is, that many users - in my experience - have Bluetooth turned off, so it can result in additional UI dialogs popping up, asking the user to turn on Bluetooth. Regarding doing everything via Bluetooth or maybe BLE: I have been following the work that Airbitz has done around that, but personally I prefer the NFC interaction of I touch what I want to pay rather than a payment request comes to me through the air and I figure out whether it is meant for me/is legitimate. ## NFC data formats ## A bit of background for those who are not that familiar with NFC: Most Bitcoin wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I am aware (with CoinBlesk being an exception, which uses host-based card emulation, if I understand it correctly). NDEF defines a number of record types, among them 'URI' and 'Mime Type
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Andy Schroder On 02/22/2015 05:48 PM, Eric Voskuil wrote: One correction inline below. e On 02/22/2015 02:39 PM, Eric Voskuil wrote: Hi Jan, This is really nice work. WRT the Schroder and Schildbach proposal, the generalization of the r and payment_url parameters makes sense, with only the potential backward compat issue on payment_url. TBIP75 furthermore proposes to include an additional 'h' parameter which would be a hash of the BIP70 payment request, preventing a MITM attack on the Bluetooth channel even if the BIP70 payment request isn't signed. This would have also been my suggestion, although I know that Mike Hearn has raised concerns about this approach. One being, that one needs to finalize the BIP70 payment request at the time the QR code and NFC URI is generated. ... 3) Are there other comments regarding 'h' parameter as per TBIP75? Yes, this design is problematic from a privacy standpoint. Anyone within the rather significant range of the Bluetooth terminal is able to capture payment requests and correlate them to people. In other words it can be used to automate tainting. The problem is easily resolved by recognizing that, in the envisioned face-to-face trade, proximity is the source of trust. Even in the above proposal the h parameter is trusted because it was obtained by proximity to the NFC terminal. The presumption is that this proximity produces a private channel. As such the tap should transfer a session key used for symmetric block cipher over the Bluetooth channel. This also resolves the issue of needing to formulate the payment request before the NFC. As an aside, in other scenarios, such as an automated dispenser, this presumption does not hold. The merchant is not present to guard against device tampering. Those scenarios can be secured using BIP70, but cannot guarantee privacy. The other differences I have with the proposal pertain to efficiency, not privacy or integrity of the transaction: The proposed resource name is redundant with any unique identifier for the session. For example, the h parameter is sufficient. But with the establishment of a session key both as I propose above, the parties can derive a sufficiently unique public resource name from a hash of the key. An additional advantage is that the resource name can be fixed-length, simplifying the encoding/decoding. The MAC address (and resource name) should be encoded using base58. This The MAC address (and session key) should be encoded using base58. This As I mentioned in my other e-mail, I don't know that we can consider this NFC a private channel, so I don't think a session key should be transmitted over it. is shorter than base16, is often shorter than base64, better standardized and does not require URI encoding, and is generally available to implementers. There is no need for the establishment of two Bluetooth services. I would change the payment_url recommendation so that the list order represents a recommended ordering provided by the terminal for the wallet. I wrote up my thoughts on these considerations last year and recently revised it by adding a section at the end to incorporate the r and payment_url generalizations from Andreas and Andy. The order is set so that it maintains backwards compatibility by providing the https request first. As mentioned in the proposal, the order of the r parameters has the recommended (but not required) priority. The wallet is encouraged to use the same protocol (but not required). https://github.com/evoskuil/bips/tree/master/docs e On 02/22/2015 11:08 AM, Jan Vornberger wrote: Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. Only the terminal needs an internet connection. Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch in the future) on the NFC pad, confirms the transaction on their phone (or smartwatch) and the transaction completes via Bluetooth and/or the phone's internet connection. You can see a prototype in action here: https://www.youtube.com/watch?v=P7vKHMoapr8 The above demo uses a release version of Schildbach's Bitcoin Wallet, so it works as shown today. However, some parts - especially the Bluetooth stuff - are custom extensions of Schildbach's wallet which are not yet standard. I'm writing this post to document my experience implementing NFC and offline payments and hope to move the discussion forward around standardizing some of this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2] follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are relevant here as well. ## NFC vs Bluetooth vs NFC+Bluetooth ## Before I get into the implementation details, a few words for why I decided to go
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
Hello, With the recent discussion started today regarding another bluetooth communication proposal created by Airbitz, I'd like to bring people's attention back to this proposal that saw little discussion last fall. I guess I'm not sure why two proposals are being created. Is their some advantage of using bluetooth low energy over standard bluetooth (I'm not well versed in bluetooth low energy)? This NFC coupled approach seems to avoid a lot of issues with identifying the correct payee. You can see this proposed scheme demonstrated in action in a POS application in the video link below which demonstrates it with my fuel pump and Andreas Schildbach's wallet. There was a small discussion that occurred after my original announcement below. If you are new to this e-mail list, you can find an archive of those few replies here: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html Since this original announcement, a few improvements have been made to the proposal: 1. Improved documentation and explanation of the use cases in Schildbach's wallet's wiki 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests 2. Issue with the payment_url field has resolved by changing to a repeated field and requiring the wallet to search for the protocol they want to use, rather than expecting it to be a certain element number in the list. 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki Although there are some interesting use cases of Airbitz's proposal's work flow, tapping an NFC radio with a 5 mm range requires much less brain power and time than picking the correct name on the app's screen. The manual name picking is going to be especially crazy in a very congested location. The payer isn't ever going to want to have to try and figure out what register or payment terminal they are at for most applications I would ever use. I'd like to see something happen with this technology. I've also noticed that micropayment channels have little formality to being established practically and it would be awesome if they could be managed over bluetooth as well. Maybe more improvements to the payment protocol can simultaneously result (and also extended to bluetooth) that embrace the establishment of micropayment channels. Andy Schroder On 10/17/2014 03:58 PM, Andy Schroder wrote: Hello, I'd like to introduce two proposed BIPs. They are primarily focused on implementing the payment protocol using bluetooth connections. I've been working on automated point of sale devices and bluetooth communication is critical in my mind due to the potential lack of internet access at many points of sale, either due to lack of cellular internet coverage, lack of payee providing wireless internet, and/or due to financial constraints of the payer prohibiting them from maintaining a cellular internet service plan. These BIPs are largely modeled after the current functionality of Andreas Schildbach's android Bitcoin Wallet's bluetooth capability. I've discussed the communication scheme with him in depth and believe these proposals to clearly and accurately represent the communication scheme. There is also an additional h= parameter added to the bitcoin: URI scheme which applies to both bluetooth and http payment protocol requests which allows for a hash of the payment request to be included. This hash was proposed by Andreas as an amendment to BIP72, but others preferred not to amend BIP72 since it has already been put into place. The current version of Schildbach's bitcoin wallet already supports the h parameter. I'd appreciate feedback from everyone, particularly wallet developers as widespread bluetooth support among wallets is very important to me. I'm also very new to this mailing list as well as the BIP writing process, so I'd appreciate your understanding if my conventions are not standard. I am currently using the naming conventions TBIP, so that I can propose /temporary/ BIP numbers, and cross reference between the two. Obviously these will change if the BIPs are formally adopted. You can find a copy of these proposed BIPs at the following links: * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki If you are interested, you can see a demonstration of many of the proposed features using Schildbach's wallet and my fuel pump in a video I recently created: https://youtu.be/kkVAhA75k1Y . The main thing not implemented is multiple URLs for the payment protocol, so, as a hack, I'm just presenting https vi QR code and bluetooth via NFC on my fuel pump for now. There are a few known issues that could be improved to this bluetooth communication scheme as well as the general payment protocol and myself and Andreas would like to receive feedback regarding concerns and potential solutions. Some
[Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
then goes to spend the funds later, they don't necessarily have to give their payees as much knowledge of their balances and spending and receiving habits and sources. As the payment protocol currently is requiring all output amounts to be matched exactly for each output, there is no flexibility given to the payer in order to reduce a merging or unnecessary diverging of account funds, which can reduce the privacy of both the payer and the payee. If the payee were given the option to allow the payer the option to divide the amounts amount the outputs intelligently, there can be some privacy gained. * Amount of data stored in QR codes may be getting large when a backwards compatible URL is used (for wallets that don't support the payment protocol) and can be difficult to scan with outdoor screens that have an extra weather resistant pane when in direct sunlight. * The number of offline transactions of a wallet is limited to the known unspent outputs when they go offline. Long term, I'd like to see wallet devices that can use systems such as Kryptoradio's DVB-T based broadcast (but this will need yet another radio!). Another project may be to develop a blockchain query protocol of some kind where retailers can provide access to blockchain data so that customer's wallets can update their known unspent outputs via bluetooth. It's possible such a bluetooth system could be used in combination of Kryptoradio like broadcasts to provide multiple blockchain references. * The additional payment_url approach is a bit sloppy of a solution in the PaymentDetails portion of the PaymentRequest. It would have been ideal to just change this from an optional field to a repeated field, however, the backwards compatibility in the protocol buffer format will provide the last item in the array for a repeated field (to a code that expects it to be an optional field), rather than the first. Because of this, backwards compatibility with https payment requests wouldn't work if the payment_url field is just changed to a repeated field. o Possible alternatives to what is described in the proposed BIP + Change payment_url to a repeated field and then reverse the order of the parameter numbers in the payment_url, compared to the bitcoin URL r parameter. + Create an additional, new payment_url_multi repeated field (or some better name), and then leave the original payment_url field in there for backwards compatibility (and then maybe phase it out in the future). o Reference + https://developers.google.com/protocol-buffers/docs/proto#updating # |optional| is compatible with |repeated|. Given serialized data of a repeated field as input, clients that expect this field to be |optional| will take the last input value if it's a primitive type field or merge all input elements if it's a message type field. Your comments and suggestions would be greatly appreciated. -- Andy Schroder signature.asc Description: OpenPGP digital signature -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
