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
|
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 1YJTGY-00047m-RR
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 20:43:10 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.181 as permitted sender)
client-ip=74.125.82.181; envelope-from=mh.in.england@gmail.com;
helo=mail-we0-f181.google.com;
Received: from mail-we0-f181.google.com ([74.125.82.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YJTGX-0004Sf-Mc
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 20:43:10 +0000
Received: by mail-we0-f181.google.com with SMTP id k48so9851110wev.12
for <bitcoin-development@lists.sourceforge.net>;
Thu, 05 Feb 2015 12:43:03 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.107.164 with SMTP id hd4mr20080wib.7.1423168983708; Thu,
05 Feb 2015 12:43:03 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Thu, 5 Feb 2015 12:43:03 -0800 (PST)
In-Reply-To: <CABdy8DL0x6_02HCxKMrQWyCDcBXsGr7+0iBt2Ez2a_kGRwjffQ@mail.gmail.com>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>
<CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>
<CABdy8DL0x6_02HCxKMrQWyCDcBXsGr7+0iBt2Ez2a_kGRwjffQ@mail.gmail.com>
Date: Thu, 5 Feb 2015 21:43:03 +0100
X-Google-Sender-Auth: Z16KszGhKIpBYFACV4W7hvxT1sA
Message-ID: <CANEZrP1RxX0V0qegOfrs+MdVYWeeJz0cecUii=rQ09kHzzgtXA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Paul Puey <paul@airbitz.co>
Content-Type: multipart/alternative; boundary=e89a8f3ba085baba86050e5d5934
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
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YJTGX-0004Sf-Mc
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 20:43:10 -0000
--e89a8f3ba085baba86050e5d5934
Content-Type: text/plain; charset=UTF-8
>
> Even if a user could get the BIP70 URL in the URI, they would still need
> internet to access the URL.
>
The way Bitcoin Wallet does it, the bitcoin URI includes a MAC address
where you can download the request from. BIP70 does not depend on internet
access or HTTP, plus, you don't have to sign them.
The name field might work but requires the merchant to set it, e.g. by
asking the payer what their name is, then typing it in, then the payer has
to wait for it to show up. By this point it's probably faster to have
scanned a QR code.
Re: security. I'll repeat what I wrote up-thread in case you didn't see it:
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.
>
--e89a8f3ba085baba86050e5d5934
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:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.800000190734=
9px">Even if a user could get the BIP70 URL in the URI, they would still ne=
ed internet to access the URL. </span></div></div></blockquote><div><br></d=
iv><div>The way Bitcoin Wallet does it, the bitcoin URI includes a MAC addr=
ess where you can download the request from. BIP70 does not depend on inter=
net access or HTTP, plus, you don't have to sign them.</div><div><br></=
div><div>The name field might work but requires the merchant to set it, e.g=
. by asking the payer what their name is, then typing it in, then the payer=
has to wait for it to show up. By this point it's probably faster to h=
ave scanned a QR code.</div><div><br></div><div>Re: security. I'll repe=
at what I wrote up-thread in case you didn't see it:</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div style=3D"font-size:12.8000001907349px">it's not=
clear to me at all that this partial address scheme is actually secure. Th=
e assumption appears to be that the MITM must match the address prefix gene=
rated by the genuine merchant. But if they can do a wireless MITM they can =
just substitute their own address prefix/partial address, no?=C2=A0</div><d=
iv style=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size=
:12.8000001907349px">To avoid MITM attacks the sender must know who they ar=
e sending money to, and that means they must see a human understandable nam=
e that's cryptographically bound to the right public key. Displaying pa=
rtial addresses to the user is not going to solve this unless users manuall=
y compare key prefixes across the screens.... which is even less convenient=
than a QR code.</div><span class=3D"im" style=3D"font-size:12.800000190734=
9px"></span></blockquote></div></div></div>
--e89a8f3ba085baba86050e5d5934--
|
