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
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
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 <eric@voskuil.org>) id 1YJWKZ-000351-G7
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 23:59:31 +0000
X-ACL-Warn:
Received: from mail-pd0-f177.google.com ([209.85.192.177])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YJWKR-0002Nv-1o
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 23:59:31 +0000
Received: by pdjy10 with SMTP id y10so10819313pdj.9
for <bitcoin-development@lists.sourceforge.net>;
Thu, 05 Feb 2015 15:59:17 -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=xSVvaNI/oJvpVg2Nme/a5e9EaeDb5stpygjwWqJfbIA=;
b=BXCkrEF3loIXjkVzsVQdknPv8WqWbk+HqjuLm664Bi/hAuVdEGV/ZCA1S0I6T1KeKG
QscZdFXhnv3RWry70gQVvXCJA6WKauG/+WtmA+X4VsEO5hbNEnrfs7bb2PcsZYyhyWGZ
UwMwtuHLIreIzG6wQsbt+Ry1FyB8T7zOUV/9Lo/dfjxoG4lvwSvkYHzqLKIWoGzSKepB
1jFQv5Zkx9ozr3B12EAI5WtkBrhDV1xdmtWy4RPKmV29qsc/DEjAHjzdvZHYA/FApem5
CNSjlIUTdz477np9DlnAgTkrl4Ep/GXPJyp7m1QE3ar3m93nnmFyRtT4qzvVjVoQqxG3
pl2Q==
X-Gm-Message-State: ALoCoQky3zezBtNVFKYoXuXhSaeheY2dQYV15+BMOhOnY0PkP2it9AyeUEpU3yvF4IMDtnY4Xj/r
X-Received: by 10.68.203.136 with SMTP id kq8mr1095901pbc.103.1423180757352;
Thu, 05 Feb 2015 15:59:17 -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 nq6sm6166084pdb.12.2015.02.05.15.59.16
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 05 Feb 2015 15:59:16 -0800 (PST)
Message-ID: <54D403E5.5090606@voskuil.org>
Date: Thu, 05 Feb 2015 15:59:33 -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: Roy Badami <roy@gnomon.org.uk>,
William Swanson <swansontec@gmail.com>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>
<CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>
<54D3D636.1030308@voskuil.org>
<CANEZrP3ekWQWeV=Yw_E=n0grORBLHaXLUh3w0EFQdz=HsjWvZw@mail.gmail.com>
<279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com>
<CANEZrP3VAWajxE=mNxb6sLSQbhaQHD=2TgRKvYrEax2PAzCi2A@mail.gmail.com>
<6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org>
<CABdy8DLRGyy5dvmVb_B3vao7Qwz-zdAC3-+2nJkg9rSsU6FLbw@mail.gmail.com>
<C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>
<CABjHNoTmj=wfjRwApZCJJTDhhwePh=VtXkJN0e3t1uQqmeMu6Q@mail.gmail.com>
<20150205233421.GP39876@giles.gnomon.org.uk>
In-Reply-To: <20150205233421.GP39876@giles.gnomon.org.uk>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="j6PQ1LOdoRJHdN1sq8HRhHRerRSkf7slo"
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: 1YJWKR-0002Nv-1o
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Paul Puey <paul@airbitz.co>
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 23:59:31 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--j6PQ1LOdoRJHdN1sq8HRhHRerRSkf7slo
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 02/05/2015 03:34 PM, Roy Badami wrote:
> For peer-to-peer payments, how common do we think that the payment is
> of an ad hoc nature rather than to a known contact?
>=20
> If I want to pay my friends/colleagues/etc over a restaurant table
> there's no reason why I couldn't already have their public keys in my
> contact list - then it would be pretty straightforward to have a
> watertight mechanism where I would know who I was paying. You could
> probably even relatively securely bootstrap a key exchange over SMS,
> relying only on the contacts already having each other in their
> phonebooks.
In this case there is no need for P2P communication, just pay to an
address you already have for the other party. If you want to avoid
address reuse, use stealth addressing.
But yes, if you don't have a stealth address for the other party you can
certainly communicate in private as peers where you trust that you share
a public key. The core issue here is really bootstrapping of that trust
in an ad hoc manner.
> As for comsumer-to-merchant transactions where the merchant is a
> bricks and mortar merchant, IMHO it absolutely has to be "pay that
> terminal over there". It's the trust model we all currently use -
> whether paying cash or card - and it's the only trust model that works
> IMHO (and customers and businesses alike are well aware of the risks
> of a fraudster standing behind the counter pretending to be an
> employee accepting payment - and by and large are pretty good at
> mitigating it). OTOH as we've discussed here before there are many
> use cases where the custoemr doesn't actually know or care about the
> name of the shop or bar they walked into but is pretty damn sure that
> they need to make payment to the person over there behind the counter.
Yes, proximity is practically the universal solution to the problem of
the payer identifying the correct seller in any face-to-face scenario.
> Granted, there are cases taht dont' fall into either of the above -
> but they're the cases that are (a) harder to figure out how to
> authenticate and consequently (b) the use cases that are going to be
> most subject to attempted fraud.
When identification is required (show me some id before I pay you) it
equates to the BIP-70 scenario in the bitcoin model. This is also
required in order guard against repudiation (give me a signed receipt).
> On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
>> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric@voskuil.org> wrote:=
>>> A MITM can receive the initial broadcast and then spoof it by jamming=
the
>>> original. You then only see one.
>>
>> You are right, of course. There is no way to make Bluetooth 100%
>> secure, since it is an over-the-air technology. You could try securing=
>> it using a CA or other identity server, but now you've excluded ad-hoc=
>> person-to-person payments. Plus, you need an active internet
>> connection to reach the CA.
>>
>> You can try using proximity as a substitute for identity, like
>> requiring NFC to kick-start the connection, but at that point you
>> might as well use QR codes.
>>
>> This BIP is not trying to provide absolute bullet-proof security,
>> since that's impossible given the physical limitations of the
>> Bluetooth technology. Instead, it's trying to provide the
>> best-possible security given those constraints. In exchange for this,
>> we get greatly enhanced usability in common scenarios.
>>
>> There are plenty of usable, real-world technologies with big security
>> holes. Anybody with lock-picking experience will tell you this, but
>> nobody is welding their front door shut. The ability to go in and out
>> is worth the security risk.
>>
>> Bluetooth payments add a whole new dimension to real-world Bitcoin
>> usability. Do we shut that down because it can't be made perfect, or
>> do we do the best we can and move forward?
>>
>> -William
>>
>> ----------------------------------------------------------------------=
--------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, i=
s your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Ta=
ke a
>> look and join the conversation now. http://goparallel.sourceforge.net/=
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
--j6PQ1LOdoRJHdN1sq8HRhHRerRSkf7slo
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
iQEcBAEBAgAGBQJU1APlAAoJEDzYwH8LXOFOOU4H/ibb1S3IRT7X08aoonYCMxq8
7TeNHPTsXeXWxVgZjhH+L66CIH13nwOm92MmFY+6BUUiD7Lq8rMTamexsoVER7xA
5EYoQa+/mK+hzs1C7h4PTstjGUtF5l/Fw/QdHc3yuuPDSNhuCFKCmHQyyFzIVADx
bj8R99DKQ9M3JTgaDMWDweXOxwwBFL1Kpfv/WnSSaZCRbWtPm2G/0GHY6Z/0Ts3V
KyA6fDfjYZF/Dm8FOds0svgqg149CyMWegangp2MrAMLgeuFqpr4EvjN/WRqwEIQ
0UT+Tfoeo3I8TquKdcjNkon6fye0jrQjXBlRYXyjjARp37zS1PGy6aunrR8i2oI=
=lOgi
-----END PGP SIGNATURE-----
--j6PQ1LOdoRJHdN1sq8HRhHRerRSkf7slo--
|
