path: root/02/62191e564207471cfc82c9ce01bb2d73a626b8

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <info@AndySchroder.com>) id 1XfDwq-0008Bg-C3
	for bitcoin-development@lists.sourceforge.net;
	Fri, 17 Oct 2014 20:16:28 +0000
X-ACL-Warn: 
Received: from uschroder.com ([74.142.93.202])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1XfDwo-0004z3-3v for bitcoin-development@lists.sourceforge.net;
	Fri, 17 Oct 2014 20:16:28 +0000
Received: from [192.168.253.4] (cpe-74-139-170-82.swo.res.rr.com
	[74.139.170.82])
	by uschroder.com (Postfix) with ESMTPSA id 26C7E22952E1F;
	Fri, 17 Oct 2014 15:58:49 -0400 (EDT)
Message-ID: <544174F8.1050208@AndySchroder.com>
Date: Fri, 17 Oct 2014 15:58:48 -0400
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: bitcoin-development@lists.sourceforge.net
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="0oMXeSTHsnFW943R55Ai1m540CjDtO7oD"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1XfDwo-0004z3-3v
Cc: Andreas Schildbach <andreas@schildbach.de>
Subject: [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, 17 Oct 2014 20:16:28 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0oMXeSTHsnFW943R55Ai1m540CjDtO7oD
Content-Type: multipart/alternative;
	boundary="------------070005000406010405040606"

This is a multi-part message in MIME format.
--------------070005000406010405040606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hello,

I'd like to introduce two proposed BIPs. They are primarily focused on=20
implementing the payment protocol using bluetooth connections. I've been =

working on automated point of sale devices and bluetooth communication=20
is critical in my mind due to the potential lack of internet access at=20
many points of sale, either due to lack of cellular internet coverage,=20
lack of payee providing wireless internet, and/or due to financial=20
constraints of the payer prohibiting them from maintaining a cellular=20
internet service plan. These BIPs are largely modeled after the current=20
functionality of Andreas Schildbach's android Bitcoin Wallet's bluetooth =

capability. I've discussed the communication scheme with him in depth=20
and believe these proposals to clearly and accurately represent the=20
communication scheme.

There is also an additional &h=3D parameter added to the bitcoin: URI=20
scheme which applies to both bluetooth and http payment protocol=20
requests which allows for a hash of the payment request to be included.=20
This hash was proposed by Andreas as an amendment to BIP72, but others=20
preferred not to amend BIP72 since it has already been put into place.=20
The current version of Schildbach's bitcoin wallet already supports the=20
"h parameter".

I'd appreciate feedback from everyone, particularly wallet developers as =

widespread bluetooth support among wallets is very important to me. I'm=20
also very new to this mailing list as well as the BIP writing process,=20
so I'd appreciate your understanding if my conventions are not standard. =

I am currently using the naming conventions "TBIP", so that I can=20
propose /temporary/ BIP numbers, and cross reference between the two.=20
Obviously these will change if the BIPs are formally adopted. You can=20
find a copy of these proposed BIPs at the following links:

  * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
  * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki


If you are interested, you can see a demonstration of many of the=20
proposed features using Schildbach's wallet and my fuel pump in a video=20
I recently created: https://youtu.be/kkVAhA75k1Y . The main thing not=20
implemented is multiple URLs for the payment protocol, so, as a hack,=20
I'm just presenting https vi QR code and bluetooth via NFC on my fuel=20
pump for now.



There are a few known issues that could be improved to this bluetooth=20
communication scheme as well as the general payment protocol and myself=20
and Andreas would like to receive feedback regarding concerns and=20
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#upd=
ating
              # "|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


--------------070005000406010405040606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html;
      charset=3DISO-8859-1">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    Hello,<br>
    <br>
    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.<br>
    <br>
    There is also an additional &amp;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".<br>
    <br>
    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 <i>temporary</i> 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:<br>
    <ul>
      <li><a class=3D"moz-txt-link-freetext" href=3D"https://github.com/A=
ndySchroder/bips/blob/master/tbip-0074.mediawiki">https://github.com/Andy=
Schroder/bips/blob/master/tbip-0074.mediawiki</a></li>
      <li><a class=3D"moz-txt-link-freetext" href=3D"https://github.com/A=
ndySchroder/bips/blob/master/tbip-0075.mediawiki">https://github.com/Andy=
Schroder/bips/blob/master/tbip-0075.mediawiki</a><br>
      </li>
    </ul>
    <br>
    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: <a class=3D"moz-txt-link-freetext"
      href=3D"https://youtu.be/kkVAhA75k1Y">https://youtu.be/kkVAhA75k1Y<=
/a>
    . 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.<br>
    <br>
    <br>
    <br>
    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:<br>
    <br>
    <ul>
      <li>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.</li>
      <li>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.</li>
      <li>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?<br>
      </li>
      <li>I'd personally like a new optional boolean field added to the
        "PaymentDetails" portion of the <span class=3D"nc">"PaymentReques=
t"





          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.</span></li>
      <li><span class=3D"nc">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.</span></li>
      <li><span class=3D"nc">The number of offline transactions of a
          wallet is limited to the known unspent outputs when they go
          offline. </span>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.</li>
      <li>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.</li>
      <ul>
        <li>Possible alternatives to what is described in the proposed
          BIP</li>
        <ul>
          <li>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".</li>
          <li>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).<br>
          </li>
        </ul>
        <li>Reference<br>
        </li>
        <ul>
          <li><a class=3D"moz-txt-link-freetext" href=3D"https://develope=
rs.google.com/protocol-buffers/docs/proto#updating">https://developers.go=
ogle.com/protocol-buffers/docs/proto#updating</a></li>
          <ul>
            <li>"<code>optional</code> is compatible with <code>repeated<=
/code>.
              Given serialized data of a repeated field as input,
              clients that expect this field to be <code>optional</code>
              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."</li>
          </ul>
        </ul>
      </ul>
    </ul>
    <br>
    <br>
    Your comments and suggestions would be greatly appreciated.<br>
    <br>
    <pre class=3D"moz-signature" cols=3D"72">--=20
Andy Schroder</pre>
  </body>
</html>

--------------070005000406010405040606--

--0oMXeSTHsnFW943R55Ai1m540CjDtO7oD
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/

iQEcBAEBAgAGBQJUQXT4AAoJEDT679stRBhrv5oIAMVA8r4ip5x3im6bUWJr3OPm
t11ZPvgcwEuZ4BgG9e/LsGXexOpnDglY/ilG+YLUV9z+GcyPUoyA0lRgk+IrJhjN
9c70SSjKy75SDhUQK0brL3lmEEmbovySx6TlJ36/klVmY0l/kNPB6HrUcxPv5Aev
XGLQBKONvsKh38CPC510wF6UcZZRl8kcBkO5/0vc1wHRNWn0px+dLN9pdlU7PTTd
YVA++9KXd6ZtprHSTHIJSxTumPeoQ59Vg1Ra6K5O683Ggm/vUVaAK2VSlJheMhsg
XIqzTJ37T8jgG9wiAOs2cFzHgq+68Jd3xQLIUhBKDkSzP1ZFGZ7sPS8FZMPAKho=
=9A5S
-----END PGP SIGNATURE-----

--0oMXeSTHsnFW943R55Ai1m540CjDtO7oD--