From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJMvf-0001f2-QQ for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 13:57:11 +0000 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; Received: from mail-wi0-f170.google.com ([209.85.212.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJMvd-0006RJ-UB for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 13:57:11 +0000 Received: by mail-wi0-f170.google.com with SMTP id bs8so2606529wib.1 for ; Thu, 05 Feb 2015 05:57:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.61.145 with SMTP id p17mr7650779wjr.35.1423144623821; Thu, 05 Feb 2015 05:57:03 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.11 with HTTP; Thu, 5 Feb 2015 05:57:03 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2015 14:57:03 +0100 X-Google-Sender-Auth: 9UH8TipVInjchrwUt26rCy3kZp0 Message-ID: From: Mike Hearn To: Andreas Schildbach Content-Type: multipart/alternative; boundary=047d7bacc0f2c458e5050e57adef X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1YJMvd-0006RJ-UB Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:57:11 -0000 --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
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 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

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'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.

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 App= le 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 iP= hone 6 launched. Normally it's closer to 10-13%. Most other markets are= similar.=C2=A0

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.

It'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 "oops I paid for someone elses s= tuff" confusion.

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
--047d7bacc0f2c458e5050e57adef--