1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
X-Google-Sender-Auth: 9UH8TipVInjchrwUt26rCy3kZp0
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
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 <bitcoin-development@lists.sourceforge.net>
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: <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: 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
<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 "=
;bitcoin:" URIs entirely and<br>
publish BIP70 payment requests instead.<br></blockquote><div><br></div><div=
>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</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'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'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.</div><div><br></div><div>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</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'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.</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--
|
