From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJXuT-0001UU-4t for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 01:40:41 +0000 X-ACL-Warn: Received: from uschroder.com ([74.142.93.202]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YJXuQ-0005Be-T0 for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 01:40:41 +0000 Received: from [192.168.253.4] (cpe-74-137-24-201.swo.res.rr.com [74.137.24.201]) by uschroder.com (Postfix) with ESMTPSA id 2FADC22B844DB; Thu, 5 Feb 2015 20:40:33 -0500 (EST) Message-ID: <54D41B90.2010208@AndySchroder.com> Date: Thu, 05 Feb 2015 20:40:32 -0500 From: Andy Schroder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Voskuil , bitcoin-development@lists.sourceforge.net References: <544174F8.1050208@AndySchroder.com> <54D3FEE9.70502@AndySchroder.com> <54D40C7D.8090804@voskuil.org> In-Reply-To: <54D40C7D.8090804@voskuil.org> X-Enigmail-Version: 1.6 OpenPGP: id=2D44186B; url=http://andyschroder.com/static/AndySchroder.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mCTodsU6dXEATRLpmx3mrLw8wMANFPasf" X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YJXuQ-0005Be-T0 Subject: Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 01:40:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mCTodsU6dXEATRLpmx3mrLw8wMANFPasf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I personally would prefer as low of range as possible for this bluetooth = application considering the connection is not yet encrypted (mentioned=20 below), and even if it were, it seems like it is always going to be=20 better in case there is some vulnerability. From my testing with a=20 bluetooth radio inside my metal cabinet, the range is ~5 meters, which=20 is more than enough. However, the connection is actually a bit slow when the whole=20 certificate chain is included (~3-4s). You can sort of see this in my=20 video (http://youtu.be/kkVAhA75k1Y?t=3D7m39s). A lot of the time is=20 actually spent verifying the signature, and I'm not sure how much of it=20 is doing the fetching (I haven't done any detailed timings using "adb=20 logcat" and looking at the log entries), but I do know it is a little=20 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=20 HTTPS payment request fetch over wifi and verification using breadwallet = on apple is much faster (<1s) than HTTPS payment request on bitcoin=20 wallet on android (apparently apple has a significantly more optimized=20 signature verification algorithm). Bottom line is that there may be ~1s=20 time transferring the data with this current bluetooth connection. Not=20 sure how slow it will be with the BLE connection. Time is everything in=20 a point of sale application. So, I guess what I am saying is it seems like the lower speed and range=20 gain with bluetooth low energy are not a benefit in my opinion. I'm not=20 sure that the latency gain will be a benefit either unless the speed=20 issues I am noticing with regular bluetooth are actually a latency issue = with just getting the connection established, or actually transmitting=20 the payment request data. How much power is going to be used for just a=20 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=20 at length? Andy Schroder On 02/05/2015 07:36 PM, Eric Voskuil wrote: > Hi Andy, > > This is good stuff. I've spent quite a bit of time on this question, bu= t > 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 n= ot >> 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 th= e >> 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 a= n >> archive of those few replies here: >> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.n= et/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-Req= uests >> 2. Issue with the payment_url field has resolved by changing to a >> repeated field and requiring the wallet to search for the protoco= l >> they want to use, rather than expecting it to be a certain elemen= t >> number in the list. >> 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.me= diawiki >> >> >> 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= =2E >> 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 notic= ed >> 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 th= e >> 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 o= n >>> 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 cellula= r >>> 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=3D 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 alread= y >>> supports the "h parameter". >>> >>> I'd appreciate feedback from everyone, particularly wallet developers= >>> as widespread bluetooth support among wallets is very important to me= =2E >>> 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.media= wiki >>> * https://github.com/AndySchroder/bips/blob/master/tbip-0075.media= wiki >>> >>> >>> 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 middl= e >>> 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 possibl= y >>> replace the refund address by submitting a forged payment messag= e >>> 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 "lik= e" >>> 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 woul= d >>> 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 th= e >>> payer's wallet to match the "Output" optional "amount" fields as= a >>> total amount of all Outputs, rather than requiring the amount fo= r >>> 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, whic= h >>> 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 b= e >>> 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 v= ia >>> bluetooth. It's possible such a bluetooth system could be used i= n >>> combination of "Kryptoradio" like broadcasts to provide multiple= >>> blockchain references. >>> * The additional payment_url approach is a bit sloppy of a solutio= n >>> in the PaymentDetails portion of the PaymentRequest. It would ha= ve >>> 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 f= or >>> 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 B= IP >>> + 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 fie= ld >>> (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/prot= o#updating >>> # "|optional| is compatible with |repeated|. Given >>> serialized data of a repeated field as input, client= s >>> that expect this field to be |optional| will take th= e >>> last input value if it's a primitive type field or >>> merge all input elements if it's a message type fiel= d." >>> >>> >>> >>> Your comments and suggestions would be greatly appreciated. >>> >>> --=20 >>> Andy Schroder >>> >> >> >> ----------------------------------------------------------------------= -------- >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, i= s your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Ta= ke 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 >> --mCTodsU6dXEATRLpmx3mrLw8wMANFPasf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJU1BuQAAoJEDT679stRBhrVa8H/3wDDZoxdq+l9btT4xECDBFO ijPR4N92n8u3xvbRgfbycG/Fm5qpGfSvIOxt6lMQ1ArsPCP/oS4KQfaryc90H441 oNDq8m1gTH5KbwUiPt+KI7NdNaVQrF3dCwpuBEikesF+EJuynTa7JoD+hl/keAwp wpp9d1co7R6dL2SjMwm0aGTFNz8PV6kvZi5Y/YOlRCJ4a5D+ousEmpFf0cs/kwuf XMqtlDv3Mdo4WAZ6wivCsOLnZWcYAqu///RryGDd1KjsXrChxvPi7I6o9FegQ+0d zV0LdOvHqNIKWP5DedgdR3qZ2dpp5i2jUstJTXDinydQVSe23OnHuALFVy3VmMA= =DYKj -----END PGP SIGNATURE----- --mCTodsU6dXEATRLpmx3mrLw8wMANFPasf--