From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJWty-00051j-2k for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 00:36:06 +0000 X-ACL-Warn: Received: from mail-pd0-f173.google.com ([209.85.192.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJWtw-0003pL-0i for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 00:36:06 +0000 Received: by pdbft15 with SMTP id ft15so11016711pdb.11 for ; Thu, 05 Feb 2015 16:35:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=NDsz5gmeCGC2CHHU6aa8yToTzBRzowNudWa4VgW4o6Q=; b=PwoJhgDWoSfmFZaAYUGPOV+U3UpGGHGRCymouQXM2zMxFwXvBXBi9eqAVAkcjTQamn oiqkEHK4aSJBvyVzYLYaP/aavHbX57Uz6duEnNCcOBbX2s3V24RC8ar2OfkaRI2jrbfb spknvqDLJoUBBxDT5he5acKWEMAXbBNavBBiUlVpf5nJczp4xsLzx9+tLOI8IaClvM0k Q5NjOyl+yhKlzdUJ0XleK50ddNqiqhFKO1V+fSsDiOFMsKh1oFcqzjmQI6ymkRpJ3ing o5w4CG6GqAZewVRq47t9SIKMseF8jMyPOY3At3554/MIJwBeUNkfA56hlWoInydWsPrK 9PWg== X-Gm-Message-State: ALoCoQmgp+IVVIOReS1iB8/AoWF2xi0V1cpE4M8a/ai6EHRd8U9u5qZUCswtcJkiTF14xpqGnJae X-Received: by 10.70.42.208 with SMTP id q16mr1391204pdl.56.1423182958319; Thu, 05 Feb 2015 16:35:58 -0800 (PST) Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net. [50.135.46.157]) by mx.google.com with ESMTPSA id zb8sm6223072pac.45.2015.02.05.16.35.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 16:35:57 -0800 (PST) Message-ID: <54D40C7D.8090804@voskuil.org> Date: Thu, 05 Feb 2015 16:36:13 -0800 From: Eric Voskuil User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andy Schroder , bitcoin-development@lists.sourceforge.net References: <544174F8.1050208@AndySchroder.com> <54D3FEE9.70502@AndySchroder.com> In-Reply-To: <54D3FEE9.70502@AndySchroder.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rD3NL0GRniW68GAjDnoTRpNwKkp2Mh4a6" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YJWtw-0003pL-0i 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 00:36:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rD3NL0GRniW68GAjDnoTRpNwKkp2Mh4a6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, >=20 > 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 no= t > well versed in bluetooth low energy)? This NFC coupled approach seems t= o > 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. >=20 > 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.ne= t/msg06354.html >=20 > Since this original announcement, a few improvements have been made to > the proposal: >=20 > 1. Improved documentation and explanation of the use cases in > Schildbach's wallet's wiki > 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Reque= sts > 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.medi= awiki >=20 >=20 > 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. >=20 > I'd like to see something happen with this technology. I've also notice= d > 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. >=20 >=20 >=20 > Andy Schroder >=20 > 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=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 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.mediawi= ki >> * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawi= ki >> >> >> 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. >> >> --=20 >> Andy Schroder >> >=20 >=20 >=20 > -----------------------------------------------------------------------= ------- > 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. Tak= e a > look and join the conversation now. http://goparallel.sourceforge.net/ >=20 >=20 >=20 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --rD3NL0GRniW68GAjDnoTRpNwKkp2Mh4a6 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 iQEcBAEBAgAGBQJU1Ax9AAoJEDzYwH8LXOFOMOMIAJw5yhfBMO11WnfFEmYE+xS0 rlwVAYE8ix2nfZQGxBAxfL+amr7+66Byo+nR3vaN2s1bikbDpAezezMoJ0x5Rg22 fRYSHXuwz696VBJpaXD2PIj830FFKlNtVzV5P8fG3bHC9HE52yDMHwr+Llwyz/v0 u/xP32GumOPdVVa9Ka6O/USMQ+G4d1+GCIhAlWGTWQ3VORPAzpPMCEDb+wq5kozE raEV4W9OtFmdKrjtjREAgJzGCNlahzvfTd73ZD569QkejXjgSDk5sTJ1cJRNVGpe 6GgZkHIBm7YmFlTy3q6WwhcCuRFAjTHDxnskY/ozujrWh7T9lSacI7c0JoaJAz0= =UWjm -----END PGP SIGNATURE----- --rD3NL0GRniW68GAjDnoTRpNwKkp2Mh4a6--