path: root/c1/717198d5ee8cdaab0e1fd77dc16159bd82a32c

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 <info@AndySchroder.com>) 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 <info@AndySchroder.com>
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 <eric@voskuil.org>, 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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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--