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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <eric@voskuil.org>) id 1YJTHp-00033z-QK
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 20:44:29 +0000
X-ACL-Warn:
Received: from mail-pa0-f52.google.com ([209.85.220.52])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YJTHo-00040j-Ns
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 20:44:29 +0000
Received: by mail-pa0-f52.google.com with SMTP id kq14so4728207pab.11
for <bitcoin-development@lists.sourceforge.net>;
Thu, 05 Feb 2015 12:44:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type;
bh=+KCZ95cUvOkKoiRUKKYeYMxsBIxnfM3OTZQ6xFcUHIE=;
b=lFofW4sLrkXzu1K1ijA62Bn/vwKfULSI6P9xlzZDg6g1ubX0roKyYB2I1WZBVhRCtL
y0E/Osu6Xcbes7xEJh+wsDqdo5fY846/kAQcgUo8DDivqwWWnHteRBu//Zk8zNx2tO/W
iZfKID6mbRypiRolSh9FKm4Z4A/FGqwFDhfFCzL9IwaJv5V3SA7cAd9bZR9QknJ3AQzF
yQUbDneEtS5SOU+3Y4y1XcEknb8MLphRCwnBTrkrQ6w0GfR9iSZY6bGPu4mFypz/Xt8V
t9rodiPz4J1G2S/BcLREOlv3sD1+eOeT0SGZUr0aPVlyNd4ex0wVY6kqqkF2jAuuW25W
HqtA==
X-Gm-Message-State: ALoCoQm21muxuUPXblfMnpBmRnrG38rnJJz9aP1sw+E+JPUXhdaMFwqySADMjMhICXg1vm8ArmYz
X-Received: by 10.66.220.131 with SMTP id pw3mr7803883pac.123.1423169062965;
Thu, 05 Feb 2015 12:44:22 -0800 (PST)
Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net.
[50.135.46.157])
by mx.google.com with ESMTPSA id cb9sm5954286pad.46.2015.02.05.12.44.21
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 05 Feb 2015 12:44:22 -0800 (PST)
Message-ID: <54D3D636.1030308@voskuil.org>
Date: Thu, 05 Feb 2015 12:44:38 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Mike Hearn <mike@plan99.net>, Paul Puey <paul@airbitz.co>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>
<CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>
In-Reply-To: <CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="P8NRiHJPGpFkBSUCOpaJFJ9e9xIc562ig"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YJTHo-00040j-Ns
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:44:29 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--P8NRiHJPGpFkBSUCOpaJFJ9e9xIc562ig
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 02/05/2015 12:28 PM, Mike Hearn wrote:
> The donation to live performer example is good - there's no issue of
> accidentally paying for someone else in this context as there's only on=
e
> recipient, but many senders.
I'm not sure you could assume this, even if the payer only received one
broadcast. And if the payer receives multiple, it constitutes a DOS on
the scenario, potentially unintentional.
> The issue of confused payments remains in other situations though.
Agree, the problem of the payer strongly identifying the receiver
requires either proximity (NFC or QR code scan from the known-good
source) or PKI/WoT. The problem can't be resolved through a broadcast.
> For the coffee shop use case, it'd be nicer (I think) if we aim for a
> Square-style UI where the device broadcasts a (link to) a photo of the
> user combined with a bluetooth MAC. Then the merchant tablet can show
> faces of people in the shop, and can push a payment request to the user=
s
> device. That device can then buzz the user, show a confirmation screen,=
> put something on their smart watch etc or just auto-authorise the
> payment because the BIP70 signature is from a trusted merchant. User
> never even needs to touch their phone at all.
I'm imagining myself walking around broadcasting my photo and MAC
address while hucksters push payment requests to me for approval, while
recording my photo and correlating it to my address. It will pretty
quickly turn in to a scenario where I need to touch something before
this is turned on.
> On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <paul@airbitz.co
> <mailto:paul@airbitz.co>> wrote:
>=20
> The BIP70 protocol would preclude individuals from utilizing the P2=
P
> transfer spec. It would also require that a Sender have internet
> connectivity to get the payment protocol info. BLE could enable
> payment w/o internet by first transferring the URI to from Recipien=
t
> to Sender. Then in the future, we could sign a Tx and send it over
> BLE back to the recipient (who would still need internet to verify
> the Tx). This is an important use case for areas with poor 3G/4G
> connectivity as I've experience myself.
>=20
> Also, due to Android issues, NFC is incredibly clunky. The URI
> Sender is required to tap the screen *while* the two phones are in
> contact. We support NFC the same way Bitcoin Wallet does, but unles=
s
> the payment recipient has a custom Android device (which a merchant=
> might) then the usage model is worse than scanning a QR code. BLE
> also allows people to pay at a distance such as for a donation to a=
> live performer. We'll look at adding this to the Motivation section=
=2E
>=20
> From: Andreas Schildbach <andreas@sc...> - 2015-02-05 13:47:04
>=20
> Thanks Paul, for writing up your protocol!
>=20
> First thoughts:
>=20
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely=
and
> publish BIP70 payment requests instead. URIs mainly stick around be=
cause
> of QR codes limited capacity. BIP70 would partly address the "copyc=
at"
> problem by signing payment requests.
>=20
> In your Motivation section, I miss some words about NFC. NFC alread=
y
> addresses all of the usability issues mentioned and is supported by=
> mobile wallets since 2011. That doesn't mean your method doesn't ma=
ke
> sense in some situations, but I think it should be explained why to=
> prefer broadcasting payment requests over picking them up via near =
field
> radio.
--P8NRiHJPGpFkBSUCOpaJFJ9e9xIc562ig
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU09Y2AAoJEDzYwH8LXOFOC+MH/R73T01/C5REuXbOEPRjk3vU
nW9GV7gIAAlihRJ9pew18cBDU9dQTYvydbNZb33ihYqkarqDE5UsfAam9iSb57B/
NjQtLPk2xqxFK0/uafA8jcBoHK0J7WYPJYnVXEfMk7eJAniHpINxYirmb6QiX89F
VyNF+iozO2DnJCvlc8DR4fmuOXDV33myH/8dLUa/IvDOv3+2+u97HBUawV+U8n8r
jJahrXzAswRF/0ilLDD+mpF1a0R1LL+ULTi+qgrqxs5MHPqm8G0Y1FAgsL59ox5Q
NhIsOV/YXNoYZcLA2gO2bcHoFmeO7dtofSC61nd9q7CzHw3drB5N7eSVC9DbCik=
=eyzN
-----END PGP SIGNATURE-----
--P8NRiHJPGpFkBSUCOpaJFJ9e9xIc562ig--
|
