Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
I think the Bitcoin community needs a good person-to-person payment protocol for BLE simply because Bluetooth LE is effectively peer-to-peer. Unlike NFC or conventional Bluetooth, a $5 micro can be either the master or slave and talk directly to other $5 micros nearby. [ASIDE... BLE is also the first wireless tech that Apple has allowed us free access to. They have claimed all NFC/RFID connections for their own Pay junk, and Bluetooth accessories are all locked down into their make for iphone program which literally requires a letter from your lawyer to enter. Of course Apple is just one vendor.] Surely, as a community, we can make a rock-solid P2P protocol that is resistant to spoofing and vandalism. I'm a big fan of putting crypto to good use, and doing a slightly more complex protocol involving EC signing of nonces sounds great. My only change to the RedPhone based commit protocol proposed previously, is I'd like the confirmation code to be a 6-digit decimal number rather than words. Wordlists are good for Red phone's audio application, but it's a lot easier to display a 6-digit code on vending machines, small mobile screens, and printed receipts. Just my two cents. --- Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10 pgpaNC0CJGzTx.pgp Description: PGP 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
On 02/06/2015 01:36 AM, Eric Voskuil wrote: The main advantage of BLE over BT is that it uses much less power, with a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can be even greater and connection latency lower than BT. For payment purposes the lower bandwidth isn't much of a hit. I'm all for extending the BT:mac scheme to Bluetooth LE. If you have ideas how this can be done please let us know. I haven't had a chance to play around with LE because none of my devices support it. I suspect the way how Bluetooth LE transfers files (like payment requests) is opening a plain old Bluetooth socket. If this is true, I'm afraid Bluetooth LE would not add anything for sending the BIP70 messages back and forth. Note signed payment requests can easily be 4 kB in size, so speed *does* matter. -- 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
On 02/06/2015 12:40 AM, Andreas Schildbach wrote: On 02/06/2015 01:36 AM, Eric Voskuil wrote: The main advantage of BLE over BT is that it uses much less power, with a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can be even greater and connection latency lower than BT. For payment purposes the lower bandwidth isn't much of a hit. I'm all for extending the BT:mac scheme to Bluetooth LE. If you have ideas how this can be done please let us know. I haven't had a chance to play around with LE because none of my devices support it. I suspect the way how Bluetooth LE transfers files (like payment requests) is opening a plain old Bluetooth socket. If this is true, I'm afraid Bluetooth LE would not add anything for sending the BIP70 messages back and forth. Note signed payment requests can easily be 4 kB in size, so speed *does* matter. Hi Andreas, I haven't expressed any preference for BLE, just answering questions that were raised about it. The main thing that BLE brings to the table is increased battery life, but with larger transfers that benefit is reduced. 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
BLE meets a different use case than regular Bluetooth. BLE is designed to allow always-on broadcast beacons which are conceptually similar to NFC tags, with very low power requirements. The tradeoff for this ultra-low power consumption and always on nature is the same as with NFC tags: you get very little space for data, and they are essentially one way. That's why a common use case for it is to trigger some other mechanism like a classical Bluetooth socket or HTTPS connection. I think BLE has a role to play in Bitcoin payments, but probably not for actually transferring payment data. Rather, a merchant should be able to drop a BLE beacon in their shop, and then wallet apps can use that to learn where to download a payment request/upload a payment message. But the actual data transfer would still take place over Bluetooth, Wifi or the internet. That leads to the question of what the beacon broadcasts. A bitcoin URI is the obvious answer: the problem is a URI contains an address. No problem for the throw money at a live performer use case but a problem for the cafe use case. If we are willing to mandate BIP70 and remove the static address part from the URI the we get a uri that points to a url which is a bit inefficient but at least lets us distinguish bitcoin beacons from other kinds. That still leaves the fundamental question raised by the Airbitz spec - how does your wallet download the right payment request? Unfortunately that's a tough UI problem. I don't think comparing long hex strings manually is a good way to go. This seems less user friendly than a QR code. Once we solve that problem, how BLE beacons can trigger payments will all fall into place. The tech part isn't the hard part. -- 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] 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 of
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
Hi Andy, This is good stuff. I've spent quite a bit of time on this question, but set aside most of it earlier in the year in order to make some progress in other areas. I did review what I found available at the time pertaining to the Schildbach implementation and these questions. Skimming the links now I'm encouraged, but I see several things that I'd like to discuss at greater length than is appropriate here. The main advantage of BLE over BT is that it uses much less power, with a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can be even greater and connection latency lower than BT. For payment purposes the lower bandwidth isn't much of a hit. e On 02/05/2015 03:38 PM, Andy Schroder wrote: 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:
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
Agree, range is not an issue. The trade-off is in battery vs. total time, which would be influenced primarily by the battery sensitivity of the platform. I'll send you a note to follow up. e On 02/05/2015 05:40 PM, Andy Schroder wrote: Hello, I personally would prefer as low of range as possible for this bluetooth application considering the connection is not yet encrypted (mentioned below), and even if it were, it seems like it is always going to be better in case there is some vulnerability. From my testing with a bluetooth radio inside my metal cabinet, the range is ~5 meters, which is more than enough. However, the connection is actually a bit slow when the whole certificate chain is included (~3-4s). You can sort of see this in my video (http://youtu.be/kkVAhA75k1Y?t=7m39s). A lot of the time is actually spent verifying the signature, and I'm not sure how much of it is doing the fetching (I haven't done any detailed timings using adb logcat and looking at the log entries), but I do know it is a little slower than an HTTPS payment request fetch over wifi (~2-3s). The reason I know most of the time is the signature verification is because an HTTPS payment request fetch over wifi and verification using breadwallet on apple is much faster (1s) than HTTPS payment request on bitcoin wallet on android (apparently apple has a significantly more optimized signature verification algorithm). Bottom line is that there may be ~1s time transferring the data with this current bluetooth connection. Not sure how slow it will be with the BLE connection. Time is everything in a point of sale application. So, I guess what I am saying is it seems like the lower speed and range gain with bluetooth low energy are not a benefit in my opinion. I'm not sure that the latency gain will be a benefit either unless the speed issues I am noticing with regular bluetooth are actually a latency issue with just getting the connection established, or actually transmitting the payment request data. How much power is going to be used for just a few second payment? It's not like the bluetooth connection is maintained for a long time like it may be in other non bitcoin use cases. Where is a more appropriate place to discuss the other issues you have at length? 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/20/2014 12:50 PM, Mike Hearn wrote: One thing this brings up is the never-resolved issue of whether BIPs should document how we'd *like* things to work, or how things *actually do* work. BIP32 is an example of the former - it was new technology and the spec was finalised before any wallets actually implemented it. BIP 44 is an example of the latter, it basically documents how myTREZOR works and as such there was minimal or no scope for changes to it. Of course both kinds of document are valuable. You also have things like BIP43 that encourage people to reserve BIP numbers to avoid namespace collisions even if their work does not affect any other project. There should be an efficient process for informational BIPs of this type. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUR9T1AAoJEMP3uyY4RQ21ADgH/0JUnkrAzKiBrtFcoXNTEkNl 7npCPY90zQDXk0RN0sV49ralMg/j71azHKmdeH3XHPF2BG3mC4+7TejhJkDEoCoB fzVyQ/a7MSz3Hnxh0iwx/4p+8A3v6oI6h3yDJeCrwdMudGYA2OfyQuFdrSuchHp6 j0yJpdxxEwtc9A/7SKk5R7yrLqeeLs4OCk2Ep8mZfCQyWssXvlJzd0IDvYZiUHrM jwLgDCAUNIotEqF4sPzxUMCUkQH3okeVhND/WvoDh8EIrE6l48I19CfDax3gJUU+ 4eI5Ooba3SRu5a8cf3V/lgtdbpJJ4i1UdpcjeWNAz1w/P1NVrWN4uJgzUilh6zU= =OWdW -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
Hey Andy, Thanks for starting this discussion! One thing this brings up is the never-resolved issue of whether BIPs should document how we'd *like* things to work, or how things *actually do* work. BIP32 is an example of the former - it was new technology and the spec was finalised before any wallets actually implemented it. BIP 44 is an example of the latter, it basically documents how myTREZOR works and as such there was minimal or no scope for changes to it. Of course both kinds of document are valuable. Currently these specs document how Andreas' app already works. Whilst preserving compatibility with existing Android apps is surely useful, having a well designed protocol is also good. The current protocol has several problems. I don't know which is more important right now and don't have a strong opinion on that. My gut feeling is that these documents should possibly be just wiki pages on Andreas' github. Then if the protocol is brought to a point where it seems pretty good, maybe it can be BIPped at that point. Alternatively, if developers of other wallet apps feel they'd like a BIP right now even in the current state, that would be a very important data point. Re: the actual specs: - There may seem to be some inconsistency in the connection header messages IMHO we could live with that. Although Android apps are updatable, perfect header format is probably not worth the inevitable hassle and transition period that would result. - The current method uses an unauthenticated bluetooth connection for bluetooth 2.1 This on the other hand is not excellent. This is actually my fault - the first Bluetooth support in Bitcoin Wallet for Android was written by me in a frantic Berlin hackathon over a weekend. We barely got it working at all by the end, so doing encryption/auth was out of the question. Then I went back to more important tasks and what got shipped was a cleaned up/robustified version of that. Re: hash. I'm not a fan of this approach. For one, in future there might not even BE a uri involved, e.g. consider the Square style UX where the merchant is broadcasting an endpoint via BLE and the phone just automagically connects, sees a trusted merchant and pays. Super slick, we definitely want it - but no URI. Then of course there's the usual QR code size limitations. Encrypting/authing the connection at the app layer does not have to be difficult. What we really need/want, is a simple lightweight library that does an ECDH key agreement using secp256k1, and then does AES+HMAC on framed messages. Such a protocol would be useful not only for this use case, but perhaps for encrypting/authing the p2p protocol in future as well. Once the encrypted connection is set up above the Bluetooth layer, the payment protocol request can then be signed either with a regular Bitcoin key that was in the Bitcoin URI as the payment address (when a URI is available), thus linking the request to the URI without adding any additional data by doubling up the backwards compatibility support. Or if there's no URI, then of course, the payment request must be PKI signed and the signed PaymentDetails structure can contain a copy of the public key that was used to set up the connection, thus binding the connection to a PKI identity and ensuring you're not talking to a MITM. I suspect that this is not anywhere near as hard to implement as one might think. ECDH is not a complex protocol. You certainly don't need full blown HTTPS involved. - There is no acknowledgement failure message possible in the payment protocol, only an acknowledgement message or lack of acknowledgement message. This issue seems to be a concern and as a result, the memo field is used to send an ack or nack in Schildbach's wallet. Can we add a boolean status field to the payment acknowledgement message? Ugh. I did want a way to indicate failure when we designed BIP70, but I can't remember why one wasn't included in the final spec. I think we decided the containing protocol could do this instead (normally HTTP). Abusing the memo field is definitely the wrong thing to do! Rather the Bluetooth specific encapsulation protocol should have a notion of failure. - I'd personally like a new optional boolean field added to the PaymentDetails portion of the PaymentRequest to allow for the payer's wallet to match the Output optional amount fields as a total amount of all Outputs, rather than requiring the amount for each output to be matched exactly. Extending BIP70 with more negotiable privacy features is a different effort, let's not discuss that as part of Bluetooth support. Besides, no wallet uses even the existing support for merge avoidance in BIP70. In fact Andreas' wallet is one of the blocking factors here because it violates the specs by requiring the BIP70 request to have only a single output that matches the address specified in the URI. All because he doesn't trust HTTPS :( I don't
