path: root/a5/886b17bc505000f67c79b7fcfb1d955789a195

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <alexy.kot.all@gmail.com>) id 1X1hEZ-0005j8-UV
	for bitcoin-development@lists.sourceforge.net;
	Mon, 30 Jun 2014 19:27:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.128.175 as permitted sender)
	client-ip=209.85.128.175; envelope-from=alexy.kot.all@gmail.com;
	helo=mail-ve0-f175.google.com; 
Received: from mail-ve0-f175.google.com ([209.85.128.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1X1hEY-0003Dm-3k
	for bitcoin-development@lists.sourceforge.net;
	Mon, 30 Jun 2014 19:27:23 +0000
Received: by mail-ve0-f175.google.com with SMTP id jx11so8650987veb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 30 Jun 2014 12:27:16 -0700 (PDT)
X-Received: by 10.220.182.5 with SMTP id ca5mr2492066vcb.50.1404156436502;
	Mon, 30 Jun 2014 12:27:16 -0700 (PDT)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.58.237.129 with HTTP; Mon, 30 Jun 2014 12:26:36 -0700 (PDT)
In-Reply-To: <A1269E16-63BC-44D5-B460-D793D45587AD@riseup.net>
References: <leuunm$tjk$1@ger.gmane.org>
	<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
	<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
	<CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com>
	<lge7nk$3mf$2@ger.gmane.org>
	<CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
	<CALDj+BZJ0rSKuDHdbL7ANN0Vtaa3-KGYgusqMDzzB-CUxjMz7g@mail.gmail.com>
	<CANEZrP3szn=oQS+ZuqSzjUoSAjtkyPxPWJFaU1vDW43dRNVeNQ@mail.gmail.com>
	<20140320215208.GC88006@giles.gnomon.org.uk>
	<CANEZrP3kHRJ6U-O_Jgei4U6s9GyQGvB_p5ChtcHJEkYR0wWPvQ@mail.gmail.com>
	<20140326224826.GE62995@giles.gnomon.org.uk>
	<CANEZrP2HtJsOf5zOsPz32U=Jot7U9k80yEu=hj5uMPkRC+WGsQ@mail.gmail.com>
	<lgvnc2$eu4$1@ger.gmane.org>
	<CANEZrP1==hL1mW6SWV0qXUMVVx7U_HUXtorpb7qVK2R4mOfzbg@mail.gmail.com>
	<A1269E16-63BC-44D5-B460-D793D45587AD@riseup.net>
From: Alex Kotenko <alexykot@gmail.com>
Date: Mon, 30 Jun 2014 20:26:36 +0100
X-Google-Sender-Auth: zL_1ghqDWJZzoZHkxq4GbkTHtco
Message-ID: <CALDj+BYkOyNuEiiuTgjd7L-ZeHN4Mb4034W+OeCFob1RwJn=Vg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1133d7ea9b60b204fd12a501
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(alexy.kot.all[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1X1hEY-0003Dm-3k
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
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: Mon, 30 Jun 2014 19:27:24 -0000

--001a1133d7ea9b60b204fd12a501
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It took some time but we have finally implemented bluetooth integration
offered by Andreas in our bitcoin payment terminals.

=E2=80=8BHowever it's not ideal at the moment. Basically the main problem i=
s that
in the BIP72 there is no way to provide a fallback alternative URI for
payment request fetch if client wallet supports BIP70 but doesn't not
support fetching over bluetooth or bluetooth connection fails for any
reason.
There is a way to define alternative URIs inside payment request itself,
but that doesn't really work as client first needs to get payment request
message itself somehow and this is exactly the problem.

As far as I see there is three ways to solve that:
1. add new URI parameter for bluetooth address
  (e.g. r=3Dhttp://<web_address>&rbt=3Dbt:<BT_MAC_addres>).
2. allow multiple "r" parameters
  (e.g. r=3Dhttp://<web_address>&r=3Dbt:<BT_MAC_addres>).
3. allow "r" to be an array
  (e.g. r%5B0%5D=3Dhttp://<web_address>&r%5B1%5D=3Dbt:<BT_MAC_addres>).

Option #1 isn't great at all, as it solves existing problem, but not
provides any way to solve same problem appearing again for another possible
protocol.

Options #2 & #3 may be working and seem to be nearly equal, and both are
not great in the way that URI parser behavior in these cases is not clearly
defined. I've checked through relevant RFCs and found nothing specific
about this. According to my limited web experience the array scheme is
working better than multiple repeating parameters.

So I'm looking for some advice on which route of three proposed may be
better here, or if there are any other ways I'm missing.


2014-03-27 13:31 GMT+00:00 vv01f <vv01f@riseup.net>:

> Companies can have a Cert with their name via CAcert. It requires some
> work though to get assured as an organisation.
> Did you already think about what CA is to be trusted or do users need to
> do that. The least good decision in my POV would be to accept OS/browser
> built in CAs only.
>
> Am 27.03.2014 um 11:08 schrieb Mike Hearn <mike@plan99.net>:
>
>  But these cases are the norm, rather than the exception.
>>
>
> Well, you're lucky, you live in Berlin. Most of the payments I make with
> Bitcoin are online, to websites. So this will differ between people.
>
> I wonder how critical it is. Let's say you are paying for a meal. In your
> head the place you're at is just "the little Indian restaurant on the
> corner". In the companies register and therefore certificate it's somethi=
ng
> like "Singh Food GmbH". That's probably good enough to prevent shenanigan=
s.
> Even if there's a virus on your phone, it can't really replace the cert
> with a random stolen one, otherwise your meal could show up like "IronCor=
e
> Steel Inc" or something that's obviously bogus. It'd have to be an
> incredibly smart virus that knew how to substitute one name for a differe=
nt
> one, from a large library of stolen identities, such that the swap seemed
> plausible. That sounds very hard, certainly too hard to bother with for
> stealing restaurant fees.
>
> And if a waiter at the restaurant is corrupt and they replace the cert
> with one that's for their own 1-man business "BP-Gupta" or something, OK,
> you might pay the wrong person by mistake. But eventually the corrupt
> waiter will be discovered and then someone will have proof of what they
> did. It's FAR more likely they'd just strip the signature entirely and tr=
y
> to convince you the restaurant doesn't use BIP70 at all.
>
> Still, if we want to fix this, one approach I was thinking about is to
> have a super-cheesy CA just for us that issues certs with addresses in
> them, for any name you ask for. That is, if you say you want a cert for
> "Shamrock Irish Pub, Wollishofen, Zurich, CH" then it either sends a
> postcard to that address with a code to check ownership of the address, o=
r
> it checks ownership of the place on Google Maps (which does the same
> postcard trick but for free!).
>
> That doesn't work for vending machines, but perhaps we just don't care
> about those. If a MITM steals your lunch money, boo hoo.
>
>
> -------------------------------------------------------------------------=
-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> -------------------------------------------------------------------------=
-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a1133d7ea9b60b204fd12a501
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:&#39;cou=
rier new&#39;,monospace;color:rgb(0,51,0)">It took some time but we have fi=
nally implemented bluetooth integration offered by Andreas in our bitcoin p=
ayment terminals.<br>

</div>
<div class=3D"gmail_extra"><div class=3D"gmail_default" style=3D"font-famil=
y:&#39;courier new&#39;,monospace;color:rgb(0,51,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,monospace;col=
or:rgb(0,51,0)">


=E2=80=8BHowever it&#39;s not ideal at the moment. Basically the main probl=
em is that in the BIP72 there is no way to provide a fallback alternative U=
RI for payment request fetch if client wallet supports BIP70 but doesn&#39;=
t not support fetching over bluetooth or bluetooth connection fails for any=
 reason.=C2=A0</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">There is a way to define alternative URIs inside =
payment request itself, but that doesn&#39;t really work as client first ne=
eds to get payment request message itself somehow and this=C2=A0is=C2=A0exa=
ctly the problem.</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">As far as I s=
ee there is three ways to solve that:</div>

<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">1. add new URI parameter for bluetooth address=C2=
=A0</div><div class=3D"gmail_default" style=3D"font-family:&#39;courier new=
&#39;,monospace;color:rgb(0,51,0)">

=C2=A0 (e.g. r=3Dhttp://&lt;web_address&gt;&amp;rbt=3Dbt:&lt;BT_MAC_addres&=
gt;).=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:&#39;cou=
rier new&#39;,monospace;color:rgb(0,51,0)">2. allow multiple &quot;r&quot; =
parameters=C2=A0</div>

<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">=C2=A0 (e.g. r=3Dhttp://&lt;web_address&gt;&amp;r=
=3Dbt:&lt;BT_MAC_addres&gt;).</div><div class=3D"gmail_default" style=3D"fo=
nt-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">

3. allow &quot;r&quot; to be an array=C2=A0</div><div class=3D"gmail_defaul=
t" style=3D"font-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">=
=C2=A0 (e.g. r%5B0%5D=3Dhttp://&lt;web_address&gt;&amp;r%5B1%5D=3Dbt:&lt;BT=
_MAC_addres&gt;).</div>

<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">Option #1 isn=
&#39;t great at all, as it solves existing problem, but not provides any wa=
y to solve same problem appearing again for another possible protocol.</div=
>

<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">Options #2 &a=
mp; #3 may be working and seem to be nearly equal, and both are not great i=
n the way that URI parser behavior in these cases is not clearly defined. I=
&#39;ve checked through relevant RFCs and found nothing specific about this=
. According to my limited web experience the array scheme is working better=
 than multiple repeating parameters.=C2=A0</div>

<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">So I&#39;m lo=
oking for some advice on which route of three proposed may be better here, =
or if there are any other ways I&#39;m missing.=C2=A0</div>

<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">2014-03-27 13:31 GMT+00:00 vv01f <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:vv01f@riseup.net" target=3D"_blank">vv01f@riseup.net=
</a>&gt;</span>:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"auto"><div>Companies can have a Cert with their name via CAcert=
. It requires some work though to get assured as an organisation.</div><div=
>Did you already think about what CA is to be trusted or do users need to d=
o that. The least good decision in my POV would be to accept OS/browser bui=
lt in CAs only.</div>


<div><br>Am 27.03.2014 um 11:08 schrieb Mike Hearn &lt;<a href=3D"mailto:mi=
ke@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;:<br><br></div><div=
><div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_e=
xtra">


<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex">
But these cases are the norm, rather than the exception.<br></blockquote><d=
iv><br></div><div>Well, you&#39;re lucky, you live in Berlin. Most of the p=
ayments I make with Bitcoin are online, to websites. So this will differ be=
tween people.</div>



<div></div></div></div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">I wonder how critical it is. Let&#39;s say you are paying for a=
 meal. In your head the place you&#39;re at is just &quot;the little Indian=
 restaurant on the corner&quot;. In the companies register and therefore ce=
rtificate it&#39;s something like &quot;Singh Food GmbH&quot;. That&#39;s p=
robably good enough to prevent shenanigans. Even if there&#39;s a virus on =
your phone, it can&#39;t really replace the cert with a random stolen one, =
otherwise your meal could show up like &quot;IronCore Steel Inc&quot; or so=
mething that&#39;s obviously bogus. It&#39;d have to be an incredibly smart=
 virus that knew how to substitute one name for a different one, from a lar=
ge library of stolen identities, such that the swap seemed plausible. That =
sounds very hard, certainly too hard to bother with for stealing restaurant=
 fees.</div>



<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">And if a wa=
iter at the restaurant is corrupt and they replace the cert with one that&#=
39;s for their own 1-man business &quot;BP-Gupta&quot; or something, OK, yo=
u might pay the wrong person by mistake. But eventually the corrupt waiter =
will be discovered and then someone will have proof of what they did. It&#3=
9;s FAR more likely they&#39;d just strip the signature entirely and try to=
 convince you the restaurant doesn&#39;t use BIP70 at all.</div>



<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Still, if w=
e want to fix this, one approach I was thinking about is to have a super-ch=
eesy CA just for us that issues certs with addresses in them, for any name =
you ask for. That is, if you say you want a cert for &quot;Shamrock Irish P=
ub, Wollishofen, Zurich, CH&quot; then it either sends a postcard to that a=
ddress with a code to check ownership of the address, or it checks ownershi=
p of the place on Google Maps (which does the same postcard trick but for f=
ree!).</div>



<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">That doesn&=
#39;t work for vending machines, but perhaps we just don&#39;t care about t=
hose. If a MITM steals your lunch money, boo hoo.</div><div class=3D"gmail_=
extra">



<br></div></div>
</div></blockquote></div></div><div><blockquote type=3D"cite"><div><span>--=
---------------------------------------------------------------------------=
-</span><br></div></blockquote><blockquote type=3D"cite"><div><span>_______=
________________________________________</span><br>


<span>Bitcoin-development mailing list</span><br><span><a href=3D"mailto:Bi=
tcoin-development@lists.sourceforge.net" target=3D"_blank">Bitcoin-developm=
ent@lists.sourceforge.net</a></span><br><span><a href=3D"https://lists.sour=
ceforge.net/lists/listinfo/bitcoin-development" target=3D"_blank">https://l=
ists.sourceforge.net/lists/listinfo/bitcoin-development</a></span><br>


</div></blockquote></div></div><br>----------------------------------------=
--------------------------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>

--001a1133d7ea9b60b204fd12a501--