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: >> >> * 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 the known issues are: >> >> * There may seem to be some inconsistency in the connection header >> messages between the payment request connection and the payment >> connection. This is largely because it is how Andreas originally >> implemented the communication and is hesitant to change it since >> there are many instances of is software already deployed that >> implement this scheme. >> * The current method uses an unauthenticated bluetooth connection >> for bluetooth 2.1 and newer devices (subject to man in the middle >> attacks, but not passive eavesdroppers), and an unsecure and >> unauthenticated connection for older devices. The known concerns >> here are that someone within 100 meters of the payer could track >> the bitcoin addresses used for the transaction and could possibly >> replace the refund address by submitting a forged payment message >> to the payee. Requiring bluetooth 2.1 and authenticating the >> connection out of band unfortunately don't seem to be as >> straightforward/simple of a task with most bluetooth libraries >> (although I'd love for someone to prove me wrong). It's possible >> this communication scheme could be extended to use an https "like" >> protocol that would not care if the underlying bluetooth >> connection is authenticated or encrypted. It's actually possible >> that http over a bluetooth socket (instead of tcp socket) could be >> implemented, however it is presently uncertain whether this would >> be too slow, too much overhead (both on the devices software and >> communication), or if http could easily be run over bluetooth >> sockets on all platforms. >> * 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? >> * 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. As it currently is, the payee >> can specify multiple receiving addresses in order to require a >> payer split up the payments so that when the payee 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 >> > > > > ------------------------------------------------------------------------------ > 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 >