From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJYQv-0008Fn-Vs for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 02:14:13 +0000 X-ACL-Warn: Received: from mail-pd0-f170.google.com ([209.85.192.170]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJYQu-00042G-SO for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 02:14:13 +0000 Received: by pdjy10 with SMTP id y10so11498724pdj.9 for ; Thu, 05 Feb 2015 18:14:07 -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=PZTU0ODSf4ghV+VONYZpP3lWwoqYoMVFq7FA8YjOmsY=; b=WKCigUZqGPv5r29Lj7xWQNN0SrXtHY7RWVQchNcGzEl3YrVjJRcIdoi/XLIUtTPvko 8BItpeOxLbyxzi2vIMwgMymnihapyab0WRZlbnhz6VuIX7YvQRPBOeEATPNjwJiFQK7H GdYFd10kas4b0M7Dp5WxnSEImg4IIFiovXVFmOXb9Skrxi8KnXhPQDDaVCnfW5EXOpLR e3prKdQ7CGoUpU0mp5JvsAw/2LTTwVZs4kDroCvW6ExaJAQzYHQMxoT+rqMkOpQXal7w Uws9uxLWv/GJPMnc5rzXwfBGF6Yyyd/qiqlXwTsuu3xDsC4J4nO1CycaH9tmanuoBczn xZXg== X-Gm-Message-State: ALoCoQmyAi/gTgr2DY12NV8WUv8WRH0UgfvJg5KNVDpi3NTfNk98v58905cWHdff0q+Uoy+leCsq X-Received: by 10.68.132.198 with SMTP id ow6mr1889983pbb.61.1423188847220; Thu, 05 Feb 2015 18:14:07 -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 d7sm2713076pbu.1.2015.02.05.18.14.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 18:14:06 -0800 (PST) Message-ID: <54D4237E.5@voskuil.org> Date: Thu, 05 Feb 2015 18:14:22 -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> <54D40C7D.8090804@voskuil.org> <54D41B90.2010208@AndySchroder.com> In-Reply-To: <54D41B90.2010208@AndySchroder.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tTVCmPShkljeC5JIKrDd3Bwk3rtqNcQ6h" 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: 1YJYQu-00042G-SO 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 02:14:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tTVCmPShkljeC5JIKrDd3Bwk3rtqNcQ6h Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, >=20 > I personally would prefer as low of range as possible for this bluetoot= h > 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. >=20 > 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=3D7m39s). 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 reaso= n > I know most of the time is the signature verification is because an > HTTPS payment request fetch over wifi and verification using breadwalle= t > 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. >=20 > 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 issu= e > 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 maintaine= d > for a long time like it may be in other non bitcoin use cases. >=20 >=20 > Where is a more appropriate place to discuss the other issues you have > at length? --tTVCmPShkljeC5JIKrDd3Bwk3rtqNcQ6h 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 iQEcBAEBAgAGBQJU1CN+AAoJEDzYwH8LXOFOmq4H/1eWMgXLzgGw2VsFRKdVvE7e NWSAlNazAc2zBnqjOvUg6XmwA85VKHihHKNsJaPW8hUm/Vmw/03fBEYpBgg8yLua JXra6UJjORDvTvSspdUocJRMhwSXWywes6LVwyGz583IyijLJQnZ6yVv2m/x7HXx BXJnuMs+vc25hjCRQUa8T5nhqQLxxfLmrTioj3YMn1GBhO+0r3yjv0gQOTdxyN+l FPEZiWmXTHEdZiO2KUuGnJEiO9fOd6NxTNWncNWhjiZ4RCxeJENXuS87CQ+f1t8R n0RHWoF5kj1MWrd1ddPU4v9S94ZMS1O7nLj9vzflW3HeqnjqRputEJ8MQ6wqYRE= =bdaM -----END PGP SIGNATURE----- --tTVCmPShkljeC5JIKrDd3Bwk3rtqNcQ6h--