path: root/28/f168cfdfcc4068a39691510243717a35d9ab94

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 <eric@voskuil.org>) 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 <bitcoin-development@lists.sourceforge.net>;
	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 <eric@voskuil.org>
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 <info@AndySchroder.com>, 
	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: <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 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--