Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.170 as permitted sender)
	client-ip=209.85.212.170; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f170.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <mavs84$hsi$1@ger.gmane.org>
References: <CABdy8DLisEM4AMLqYOmDSAKepE3Ec6niT7ecpXDL80yt6hg5jQ@mail.gmail.com>
	<mavs84$hsi$1@ger.gmane.org>
Date: Thu, 5 Feb 2015 14:57:03 +0100
Message-ID: <CANEZrP3Vzw5L3tOc7p+ZKY=GGhoVSTRzARgD72uP-KcqCfK4rQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=047d7bacc0f2c458e5050e57adef
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE)
 transfer of Payment URI
Precedence: list

--047d7bacc0f2c458e5050e57adef
Content-Type: text/plain; charset=UTF-8

>
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
> publish BIP70 payment requests instead.
>

Agreed - it's not clear to me at all that this partial address scheme is
actually secure. The assumption appears to be that the MITM must match the
address prefix generated by the genuine merchant. But if they can do a
wireless MITM they can just substitute their own address prefix/partial
address, no?

To avoid MITM attacks the sender must know who they are sending money to,
and that means they must see a human understandable name that's
cryptographically bound to the right public key. Displaying partial
addresses to the user is not going to solve this unless users manually
compare key prefixes across the screens.... which is even less convenient
than a QR code.

I think it should be explained why to
> prefer broadcasting payment requests over picking them up via near field
> radio.
>

This is probably an artifact of Apple's restrictions on iOS. Only the
iPhone 6 has NFC hardware and Apple don't expose it via any public API. It
can however support Bluetooth LE.

Apple isn't a big deal in Germany because iPhone only achieved about 17%
market share during the quarter when the iPhone 6 launched. Normally it's
closer to 10-13%. Most other markets are similar.

However in the USA, UK, Australia and Japan iOS is still a big deal and NFC
is going to be seen as a non-universal solution there. At least, until
Apple catches up and provides an NFC API.

It's certainly not a problem to have a working radio based broadcast
system, though the theoretician in me wonders what  happens when lots of
people are trying to pay simultaneously for something that has equal cost
..... e.g. buying movie tickets at a counter. NFC and QR codes prevent any
kind of "oops I paid for someone elses stuff" confusion.

In practice of course Bitcoin payments are not normally popular enough for
this to be a problem outside of Bitcoin community events.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">For a BIP standard, I think we should skip &quot=
;bitcoin:&quot; URIs entirely and<br>
publish BIP70 payment requests instead.<br></blockquote><div><br></div><div=
>Agreed - it&#39;s not clear to me at all that this partial address scheme =
is actually secure. The assumption appears to be that the MITM must match t=
he address prefix generated by the genuine merchant. But if they can do a w=
ireless MITM they can just substitute their own address prefix/partial addr=
ess, no?=C2=A0</div><div><br></div><div>To avoid MITM attacks the sender mu=
st know who they are sending money to, and that means they must see a human=
 understandable name that&#39;s cryptographically bound to the right public=
 key. Displaying partial addresses to the user is not going to solve this u=
nless users manually compare key prefixes across the screens.... which is e=
ven less convenient than a QR code.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">I think it should be explained why to<br>
prefer broadcasting payment requests over picking them up via near field<br=
>
radio.<br></blockquote><div><br></div><div>This is probably an artifact of =
Apple&#39;s restrictions on iOS. Only the iPhone 6 has NFC hardware and App=
le don&#39;t expose it via any public API. It can however support Bluetooth=
 LE.</div><div><br></div><div>Apple isn&#39;t a big deal in Germany because=
 iPhone only achieved about 17% market share during the quarter when the iP=
hone 6 launched. Normally it&#39;s closer to 10-13%. Most other markets are=
 similar.=C2=A0</div><div><br></div><div>However in the USA, UK, Australia =
and Japan iOS is still a big deal and NFC is going to be seen as a non-univ=
ersal solution there. At least, until Apple catches up and provides an NFC =
API.</div><div><br></div><div>It&#39;s certainly not a problem to have a wo=
rking radio based broadcast system, though the theoretician in me wonders w=
hat =C2=A0happens when lots of people are trying to pay simultaneously for =
something that has equal cost ..... e.g. buying movie tickets at a counter.=
 NFC and QR codes prevent any kind of &quot;oops I paid for someone elses s=
tuff&quot; confusion.</div><div><br></div><div>In practice of course Bitcoi=
n payments are not normally popular enough for this to be a problem outside=
 of Bitcoin community events.=C2=A0</div></div></div></div>

--047d7bacc0f2c458e5050e57adef--