path: root/c1/5c58eb29732d06f585166d9dd026f41d940dc3

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
	id 1YRe2G-0005bc-Ly for bitcoin-development@lists.sourceforge.net;
	Sat, 28 Feb 2015 09:50:12 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
Received: from plane.gmane.org ([80.91.229.3])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1YRe2D-0003gL-Sf
	for bitcoin-development@lists.sourceforge.net;
	Sat, 28 Feb 2015 09:50:12 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
	id 1YRe26-00046b-EF for bitcoin-development@lists.sourceforge.net;
	Sat, 28 Feb 2015 10:50:02 +0100
Received: from cpe-74-137-24-201.swo.res.rr.com ([74.137.24.201])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
	Sat, 28 Feb 2015 10:50:02 +0100
Received: from info by cpe-74-137-24-201.swo.res.rr.com with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 28 Feb 2015 10:50:02 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andy Schroder <info@AndySchroder.com>
Date: Sat, 28 Feb 2015 04:46:15 -0500
Message-ID: <54F18E67.4020908@AndySchroder.com>
References: <20150222190839.GA18527@odo.localdomain>	<54EA5A1C.2020701@AndySchroder.com>	<54EA60D9.8000001@voskuil.org>	<54EA66F5.2000302@AndySchroder.com>	<mcdu6b$j11$1@ger.gmane.org>
	<54EAD884.8000205@AndySchroder.com>	<54EAF570.2090602@voskuil.org>
	<54EBE809.70801@voskuil.org>	<54EC11DA.2010000@AndySchroder.com>
	<54EC605B.8080005@voskuil.org>	<54ECD5BA.7040109@AndySchroder.com>
	<54ECF7DB.3060607@voskuil.org>	<54ED0046.3030906@AndySchroder.com>
	<54ED2EE6.6020903@voskuil.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="NJAG2nIeE2diSjtL9igdRE4PmDlLssgv0"
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: cpe-74-137-24-201.swo.res.rr.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <54ED2EE6.6020903@voskuil.org>
X-Enigmail-Version: 1.6
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.4 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YRe2D-0003gL-Sf
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
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: Sat, 28 Feb 2015 09:50:12 -0000

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

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







Manually quoting a reply from Andreas that was sent privately while the=20
e-mail list was 2 days delayed delivering messages ....

On 02/25/2015 02:45 AM, Andreas Schildbach wrote:
> Bear in mind that the "bt:" scheme is already in use by ~700.000
> installations. If we change the protocol except just wrapping a secure
> layer, we should change the scheme to for example "bs:" (Bluetooth secu=
re).

This bs: is not a bad idea. Is bts: any better/clearer than bs:?

>
> That said, I don't like the idea to fold the resource name and the
> session key into one. Resource names can be shared by multiple
> protocols, for example a merchant may publish payment requests under
> bt:<mac>/r1*and*  https://<domain>/r1. If you want to save space and
> don't need resources, you can always just use bt:<mac> and a default
> resource (bt:<mac>/) is assumed.

I'm going to agree with Andreas on this. The other thing is we are=20
making the resource name derived from the public key, so we are not even =

directly sending the resource name.

>
> Have we decided on the use (or non-use) of a DHKE (or similar) protocol=

> like Mike suggested?


We are planning to send a unique public key of the payee via NFC. See=20
other e-mails now that the e-mail list finally forwarded them through=20
the other day.
















Now for Eric's e-mail... More below.


On 02/24/2015 09:09 PM, Eric Voskuil wrote:
> On 02/24/2015 02:50 PM, Andy Schroder wrote:
>> We can change "resource" to "Session ID" if you want.
>>
>> I think the URL scheme should be:
>>
>> bitcoin:[address]?r=3Dbt:<mac>&s=3D<PublicKey>
> This is a question of proper URL semantics, as applied to the "bt" sche=
me.
>
>  From rfc3986 [Uniform Resource Identifier (URI): Generic Syntax]:
>
> "The path component contains data, usually organized in hierarchical
> form, that, along with data in the non-hierarchical query component
> (Section 3.4), serves to identify a resource within the scope of the
> URI's scheme and naming authority (if any)."
>
> ...
>
> "The query component contains non-hierarchical data that, along with
> data in the path component (Section 3.3), serves to identify a resource=

> within the scope of the URI's scheme and naming authority (if any). The=

> query component is indicated by the first question mark ("?") character=

> and terminated by a number sign ("#") character or by the end of the UR=
I."
>
> https://tools.ietf.org/html/rfc3986#section-3.3
>
> The question therefore is whether <key> is (1) relative to the path
> (hierarchical) or (2) independent of the path and instead relative to
> the scheme and naming authority.
>
> The "bt" scheme does not include a naming authority, and as such the
> question is simply whether <key> is relative to "bt" or relative to the=

> path, which is <mac>. Quite clearly <key> is valid only in the context
> of <mac>, not relevant to all <mac>s.
>
> As such one must conclude that the proper form is:
>
> bt:<mac>/<key>


See my comments above.


>
>> But when connecting to the mac, the client indicates the SessionID in
>> the header, and as you say, SessionID is derived in some way from
>> PublicKey.
> Yes.
>
>> This is a slightly different format than both of your suggestions belo=
w,
>> but seems to make more sense based on what you said in your entire
>> message. The other thing is it can be used with more protocols without=

>> taking up more space in the URL.
>>
>> However, by loosing the h=3D parameter, I think we are now loosing som=
e
>> benefit it brought to https based connections if the customer doesn't
>> want to use bluetooth. Right?
> I don't believe that the BIP-70 protocol over https has any need for th=
e
> parameter. It was only useful because the NFC/BT session wasn't secured=
=2E
> So I don't think anything is lost.

This may be true. Andreas, do you agree? I feel like there was something =

in your app where it did not currently compare the domain name to domain =

name the digital signature in the payment request used though. Maybe=20
this was only for bluetooth though? However, can we trust DNS though?=20
Seems like it is not too hard to get an alternate signed certificate for =

a domain name, and if you can serve false DNS and/or change TCP/IP=20
routing, then your secure link can break down?



>
>> Also, you talk about a new public key (and session ID) for each tap. I=

>> guess I'm wondering about this though. If the public key is compromise=
d
>> on the first tap, isn't their payment request already compromised?
> Yes, but that is not the problem that non-reuse is designed to resolve.=

>
> Reuse of the public key creates a forward secrecy problem. If 1000
> sessions are recorded, and later the private key associated with the
> reused public key is compromized, all of the sessions are retroactively=

> compromised.
>
> Another problem is persistent impersonation. If the one associated
> private key is compromised, and nobody knows it, the attacker can not
> only monitor all transactions but can selectively steal payments (if
> they aren't signed and verified). This is BTW also a good reason to not=

> use HD generation of these session keys.
>
> Another problem is that any payer can use the well-known public key to
> obtain payment requests.
>
> Another problem is that without a unique public key there is no unique
> session id, so that would need to be added explicitly on the URI.



I get what you are saying, but I don't know that 2 taps with the same=20
public key is the same as 1000 uses of the same public key?



>
>> Since we are securing everything, can we change the message header
>> format from what Schildbach's bitcoin wallet implements to something
>> more consistent?
> Could you spell this out, I'm not familiar with the implementation, jus=
t
> the proposals.


If you'll check the proposed specification, the headers in each message=20
(before the serialized payment request data is sent), are consistent=20
from message to message.

https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki#Spec=
ification




>
>> Maybe we can create a new UUID for this secure service
>> so Schildbach's bitcoin wallet can still maintain backwards compatibil=
ity.
> That may be necessary depending on the implementation of existing
> terminals, but I'm not familiar enough to speculate.

I think we probably also want to combine new UUID's with Schildbach's=20
suggestion (above) to use a new "bs:" (which I suggested maybe "bts:")=20
protocol scheme.



>
> e
>
>> On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>>>>     * Add a "s=3D" parameter that uses a unique public key for each
>>>> session.
>>>>       This public key identifies the payee to the payer and payer to=
 the
>>>>       payee.
>>> This would be the simple model, which just tacks on another parameter=
 to
>>> the bitcoin URL:
>>>
>>> bitcoin:[address]?bt=3D<mac>&s=3D<key>
>>>
>>> But we should also look at the more flexible "r#" approach from your
>>> existing TBIPs, which would yield:
>>>
>>> bitcoin:[address]?r=3Dbt:<mac>/<key>
>>>
>>> and incorporate the "payment_url" list.
>>>
>>>>     * Use a base58 encoding to save space and reduce the character s=
et
>>>>       slightly.
>>> :)
>>>
>>>>     * Get rid of the resource? If a terminal is accepting payment fr=
om
>>>>       multiple customers simultaneously, it should be smart enough t=
o
>>>>       distinguish between customers based on the public key they are=

>>>>       encrypting the data with. Is this approach feasible?
>>> Yes, it is not necessary on the URL. But an id is useful in helping t=
he
>>> BT terminal identify the session without having to try all of its
>>> outstanding keys until it finds one that works.
>>>
>>> I proposed that the resource name ("session id" may be a better name)=
 be
>>> deterministically derived from the session key. Given the design chan=
ge
>>> to pass an EC public key it would need to be derived from that key (n=
ot
>>> from the session key because the receiver would not have a copy befor=
e
>>> decrypting the first BT message). So any function on the public key t=
hat
>>> reduces it to a smaller length, fixed width should be fine. Hashing i=
t
>>> first may be better as is prevents disclosure of any bits of the publ=
ic
>>> key, which should be treated as a secret during the session.
>>>
>>>>     * When you said a new public key for each tap, do you see that a=
s
>>>>       every single tap, or do you consider multiple taps from the sa=
me
>>>>       customer the same tap?
>>> Yes, since there would be no other way to distinguish between custome=
rs
>>> in some scenarios and this is the safest approach. We certainly won't=

>>> run out of numbers, and unused sessions can be discarded based on any=

>>> number of criteria, including discarding all but the most recent. Tha=
t
>>> may may be sufficient for your vending machines given there's little =
if
>>> any call for parallelism.
>>>
>>> e
>
>
> -----------------------------------------------------------------------=
-------
> Dive into the World of Parallel Programming The Go Parallel Website, sp=
onsored
> by Intel and developed in partnership with Slashdot Media, is your hub =
for all
> things parallel software development, from weekly thought leadership bl=
ogs to
> news, videos, case studies, tutorials and more. Take a look and join th=
e
> conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

<html>
  <head>
    <meta content=3D"text/html; charset=3DISO-8859-1"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      Manually quoting a reply from Andreas that was sent privately
      while the e-mail list was 2 days delayed delivering messages ....<b=
r>
      <br>
      On 02/25/2015 02:45 AM, Andreas Schildbach wrote:<br>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Bear in mind that the "bt:" scheme is already in u=
se by ~700.000
installations. If we change the protocol except just wrapping a secure
layer, we should change the scheme to for example "bs:" (Bluetooth secure=
).</pre>
      </blockquote>
      <br>
      This bs: is not a bad idea. Is bts: any better/clearer than bs:?<br=
>
      <br>
      <blockquote type=3D"cite">
        <pre wrap=3D"">

That said, I don't like the idea to fold the resource name and the
session key into one. Resource names can be shared by multiple
protocols, for example a merchant may publish payment requests under
bt:&lt;mac&gt;/r1 <b class=3D"moz-txt-star"><span class=3D"moz-txt-tag">*=
</span>and<span class=3D"moz-txt-tag">*</span></b> <a class=3D"moz-txt-li=
nk-freetext" href=3D"https://">https://</a>&lt;domain&gt;/r1. If you want=
 to save space and
don't need resources, you can always just use bt:&lt;mac&gt; and a defaul=
t
resource (bt:&lt;mac&gt;/) is assumed.</pre>
      </blockquote>
      <br>
      I'm going to agree with Andreas on this. The other thing is we are
      making the resource name derived from the public key, so we are
      not even directly sending the resource name.<br>
      <br>
      <blockquote type=3D"cite">
        <pre wrap=3D"">

Have we decided on the use (or non-use) of a DHKE (or similar) protocol
like Mike suggested?</pre>
      </blockquote>
      <br>
      <br>
      We are planning to send a unique public key of the payee via NFC.
      See other e-mails now that the e-mail list finally forwarded them
      through the other day.<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      Now for Eric's e-mail... More below.<br>
      <br>
      <br>
      On 02/24/2015 09:09 PM, Eric Voskuil wrote:<br>
    </div>
    <blockquote cite=3D"mid:54ED2EE6.6020903@voskuil.org" type=3D"cite">
      <pre wrap=3D"">On 02/24/2015 02:50 PM, Andy Schroder wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">We can change "resource" to "Session ID" if you wa=
nt.

I think the URL scheme should be:

bitcoin:[address]?r=3Dbt:&lt;mac&gt;&amp;s=3D&lt;PublicKey&gt;
</pre>
      </blockquote>
      <pre wrap=3D"">
This is a question of proper URL semantics, as applied to the "bt" scheme=
=2E

=46rom rfc3986 [Uniform Resource Identifier (URI): Generic Syntax]:

"The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any)."

=2E..

"The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a resource
within the scope of the URI's scheme and naming authority (if any). The
query component is indicated by the first question mark ("?") character
and terminated by a number sign ("#") character or by the end of the URI.=
"

<a class=3D"moz-txt-link-freetext" href=3D"https://tools.ietf.org/html/rf=
c3986#section-3.3">https://tools.ietf.org/html/rfc3986#section-3.3</a>

The question therefore is whether &lt;key&gt; is (1) relative to the path=

(hierarchical) or (2) independent of the path and instead relative to
the scheme and naming authority.

The "bt" scheme does not include a naming authority, and as such the
question is simply whether &lt;key&gt; is relative to "bt" or relative to=
 the
path, which is &lt;mac&gt;. Quite clearly &lt;key&gt; is valid only in th=
e context
of &lt;mac&gt;, not relevant to all &lt;mac&gt;s.

As such one must conclude that the proper form is:

bt:&lt;mac&gt;/&lt;key&gt;</pre>
    </blockquote>
    <br>
    <br>
    See my comments above.<br>
    <br>
    <br>
    <blockquote cite=3D"mid:54ED2EE6.6020903@voskuil.org" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">But when connecting to the mac, the client indicat=
es the SessionID in
the header, and as you say, SessionID is derived in some way from
PublicKey.
</pre>
      </blockquote>
      <pre wrap=3D"">
Yes.

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">This is a slightly different format than both of y=
our suggestions below,
but seems to make more sense based on what you said in your entire
message. The other thing is it can be used with more protocols without
taking up more space in the URL.

However, by loosing the h=3D parameter, I think we are now loosing some
benefit it brought to https based connections if the customer doesn't
want to use bluetooth. Right?
</pre>
      </blockquote>
      <pre wrap=3D"">
I don't believe that the BIP-70 protocol over https has any need for the
parameter. It was only useful because the NFC/BT session wasn't secured.
So I don't think anything is lost.</pre>
    </blockquote>
    <br>
    This may be true. Andreas, do you agree? I feel like there was
    something in your app where it did not currently compare the domain
    name to domain name the digital signature in the payment request
    used though. Maybe this was only for bluetooth though? However, can
    we trust DNS though? Seems like it is not too hard to get an
    alternate signed certificate for a domain name, and if you can serve
    false DNS and/or change TCP/IP routing, then your secure link can
    break down?<br>
    <br>
    <br>
    <br>
    <blockquote cite=3D"mid:54ED2EE6.6020903@voskuil.org" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Also, you talk about a new public key (and session=
 ID) for each tap. I
guess I'm wondering about this though. If the public key is compromised
on the first tap, isn't their payment request already compromised?
</pre>
      </blockquote>
      <pre wrap=3D"">
Yes, but that is not the problem that non-reuse is designed to resolve.

Reuse of the public key creates a forward secrecy problem. If 1000
sessions are recorded, and later the private key associated with the
reused public key is compromized, all of the sessions are retroactively
compromised.

Another problem is persistent impersonation. If the one associated
private key is compromised, and nobody knows it, the attacker can not
only monitor all transactions but can selectively steal payments (if
they aren't signed and verified). This is BTW also a good reason to not
use HD generation of these session keys.

Another problem is that any payer can use the well-known public key to
obtain payment requests.

Another problem is that without a unique public key there is no unique
session id, so that would need to be added explicitly on the URI.</pre>
    </blockquote>
    <br>
    <br>
    <br>
    I get what you are saying, but I don't know that 2 taps with the
    same public key is the same as 1000 uses of the same public key?<br>
    <br>
    <br>
    <br>
    <blockquote cite=3D"mid:54ED2EE6.6020903@voskuil.org" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Since we are securing everything, can we change th=
e message header
format from what Schildbach's bitcoin wallet implements to something
more consistent?
</pre>
      </blockquote>
      <pre wrap=3D"">
Could you spell this out, I'm not familiar with the implementation, just
the proposals.</pre>
    </blockquote>
    <br>
    <br>
    If you'll check the proposed specification, the headers in each
    message (before the serialized payment request data is sent), are
    consistent from message to message.<br>
    <br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/AndySchrode=
r/bips/blob/master/tbip-0074.mediawiki#Specification">https://github.com/=
AndySchroder/bips/blob/master/tbip-0074.mediawiki#Specification</a><br>
    <br>
    <br>
    <br>
    <br>
    <blockquote cite=3D"mid:54ED2EE6.6020903@voskuil.org" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Maybe we can create a new UUID for this secure ser=
vice
so Schildbach's bitcoin wallet can still maintain backwards compatibility=
=2E
</pre>
      </blockquote>
      <pre wrap=3D"">
That may be necessary depending on the implementation of existing
terminals, but I'm not familiar enough to speculate.</pre>
    </blockquote>
    <br>
    I think we probably also want to combine new UUID's with
    Schildbach's suggestion (above) to use a new "bs:" (which I
    suggested maybe "bts:") protocol scheme.<br>
    <br>
    <br>
    <br>
    <blockquote cite=3D"mid:54ED2EE6.6020903@voskuil.org" type=3D"cite">
      <pre wrap=3D"">

e

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">On 02/24/2015 05:14 PM, Eric Voskuil wrote:
</pre>
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <pre wrap=3D"">   * Add a "s=3D" parameter that uses a unique=
 public key for each
session.
     This public key identifies the payee to the payer and payer to the
     payee.
</pre>
          </blockquote>
          <pre wrap=3D"">This would be the simple model, which just tacks=
 on another parameter to
the bitcoin URL:

bitcoin:[address]?bt=3D&lt;mac&gt;&amp;s=3D&lt;key&gt;

But we should also look at the more flexible "r#" approach from your
existing TBIPs, which would yield:

bitcoin:[address]?r=3Dbt:&lt;mac&gt;/&lt;key&gt;

and incorporate the "payment_url" list.

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">   * Use a base58 encoding to save space and r=
educe the character set
     slightly.
</pre>
          </blockquote>
          <pre wrap=3D"">:)

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">   * Get rid of the resource? If a terminal is=
 accepting payment from
     multiple customers simultaneously, it should be smart enough to
     distinguish between customers based on the public key they are
     encrypting the data with. Is this approach feasible?
</pre>
          </blockquote>
          <pre wrap=3D"">Yes, it is not necessary on the URL. But an id i=
s useful in helping the
BT terminal identify the session without having to try all of its
outstanding keys until it finds one that works.

I proposed that the resource name ("session id" may be a better name) be
deterministically derived from the session key. Given the design change
to pass an EC public key it would need to be derived from that key (not
from the session key because the receiver would not have a copy before
decrypting the first BT message). So any function on the public key that
reduces it to a smaller length, fixed width should be fine. Hashing it
first may be better as is prevents disclosure of any bits of the public
key, which should be treated as a secret during the session.

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">   * When you said a new public key for each t=
ap, do you see that as
     every single tap, or do you consider multiple taps from the same
     customer the same tap?
</pre>
          </blockquote>
          <pre wrap=3D"">Yes, since there would be no other way to distin=
guish between customers
in some scenarios and this is the safest approach. We certainly won't
run out of numbers, and unused sessions can be discarded based on any
number of criteria, including discarding all but the most recent. That
may may be sufficient for your vending machines given there's little if
any call for parallelism.

e
</pre>
        </blockquote>
        <pre wrap=3D"">
</pre>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <br>
      <fieldset class=3D"mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap=3D"">----------------------------------------------------=
--------------------------
Dive into the World of Parallel Programming The Go Parallel Website, spon=
sored
by Intel and developed in partnership with Slashdot Media, is your hub fo=
r all
things parallel software development, from weekly thought leadership blog=
s to
news, videos, case studies, tutorials and more. Take a look and join the =

conversation now. <a class=3D"moz-txt-link-freetext" href=3D"http://gopar=
allel.sourceforge.net/">http://goparallel.sourceforge.net/</a></pre>
      <br>
      <fieldset class=3D"mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap=3D"">_______________________________________________
Bitcoin-development mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Bitcoin-development@=
lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.sourceforge.net/=
lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/l=
istinfo/bitcoin-development</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------070007090309010809060606--

--NJAG2nIeE2diSjtL9igdRE4PmDlLssgv0
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/

iQEcBAEBAgAGBQJU8Y5nAAoJEDT679stRBhrP7wH/imx+Bu0WqmDloFx07C7hHZ+
d62IfesVzJ/CqhfAnoX7aC01xT+zeZ4OJt+JKKQuYyEmwp2FXxjhnqVQekmhLube
HLKd1IFLMypoPU2tCFeMD6k5/nB6B5r9Mjp4DZE/3JZ8EO7fpvzZmqFOQV4EHGoB
jZuIB+Eg2SiKO8Yn7zKnSRx7sWY5jvRIatsZu8TyYRlzGqY+HcRipz4F1+nFqnYL
OgpNxOXrPWpdy20JjHNeMdYcxoZRAmW86M00RvmIcqISY/YgPFOWLtKpX6pUwdTh
Q/X4JtEpIh/3C7adAS7lQDIKhCrycB4UJ0xCjOVRykdF9rISUZUJhKt6REbzJ4I=
=6HUc
-----END PGP SIGNATURE-----

--NJAG2nIeE2diSjtL9igdRE4PmDlLssgv0--