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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <martin.habovstiak@gmail.com>) id 1YJVl9-00050z-CV
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 23:22:55 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175;
envelope-from=martin.habovstiak@gmail.com;
helo=mail-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YJVl7-0001eN-21
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Feb 2015 23:22:55 +0000
Received: by mail-qc0-f175.google.com with SMTP id c9so9132361qcz.6
for <bitcoin-development@lists.sourceforge.net>;
Thu, 05 Feb 2015 15:22:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.101.151 with SMTP id u23mr1502489qge.2.1423178567600;
Thu, 05 Feb 2015 15:22:47 -0800 (PST)
Received: by 10.140.19.18 with HTTP; Thu, 5 Feb 2015 15:22:47 -0800 (PST)
In-Reply-To: <20150205224909.GO39876@giles.gnomon.org.uk>
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>
<20150205224909.GO39876@giles.gnomon.org.uk>
Date: Fri, 6 Feb 2015 00:22:47 +0100
Message-ID: <CALkkCJaTemhR6xeV+Ynyw4X=Tjv+RpHmWkQBDaO0e=Uctc77SA@mail.gmail.com>
From: =?UTF-8?B?TeKStnJ0aW4gSOKStmJv4pOLxaF0aWFr?=
<martin.habovstiak@gmail.com>
To: Roy Badami <roy@gnomon.org.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(martin.habovstiak[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1YJVl7-0001eN-21
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:22:55 -0000
I would like to shortly express my opinion:
- Having BT as an alternative is good idea but it must be secure enough
- Signed BIP70 should be enough. I see only two issues regarding BIP70
(but they apply also to TCP/IP, not just BT): key revocations and MITM
attacks by governments.
- Broadcasting faces is very bad idea IMHO.
- Comparing addresses seems complicated but if hash was displayed as a
unique, picture hard to be mistake or long phrase, it could be more
convenient.
- Maybe storing public key (I do NOT mean bitcoin address!) of
merchant after successful transaction is good compromise?
Another idea: I noticed it's extremely easy to compare two strings if
they are the same size (in terms of millimeters, not number of
characters). If the hash of signing key was printed on a sign near the
POS in specified size (90% of smallest available screen?) and phone
would scale correctly, just putting the phone near the sign would be
enough to instantly spot whether the hashes are same.
Maybe instead of hex/base58 hash encoding use colored barcode. But I'm
not sure if it would improve things.
2015-02-05 23:49 GMT+01:00 Roy Badami <roy@gnomon.org.uk>:
> Personally I like the simplicity of tapping two phones together to
> make payment - it should be quicker and easier than scanning QR codes
> and it's a trust model that's hard to misunderstand.
>
> Is NFC good enough for that? I fear even with NFC it is possible to
> produce a device with longer range than one would expect. What
> happened to the idea of tapping two devices together and then
> comparing the timing of the tap (as detected by the phones'
> accelerometers) to make spoofing a transaction harder? I remember
> hearing about that years ago - is that still a thing?
>
> roy
>
> On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote:
>> A MITM can receive the initial broadcast and then spoof it by jamming th=
e original. You then only see one.
>>
>> e
>>
>> > On Feb 5, 2015, at 2:07 PM, Paul Puey <paul@airbitz.co> wrote:
>> >
>> > So if you picked up the BLE broadcast request. All you know is that *s=
omeone* within 100m is requesting bitcoin at a certain address. Not necessa=
rily who. The *name* is both optional, and possibly just a *handle* of the =
user. If I'm sitting 5 ft away from someone at dinner and wanted to pay the=
m via BLE, I might see "Monkey Dude" on my list and simply ask him "is that=
you?" If so, I send it. If there are two "Monkey Dude's" Then I have to bo=
ther with the address prefix, but not otherwise.
>> >
>> >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric@voskuil.org> wrote=
:
>> >> BLE has an advertised range of over 100m.
>> >>
>> >> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>> >>
>> >> In the case of mass surveillance that range could most likely be exte=
nded dramatically by the reviewer. I've seen WiFi ranges of over a mile wi=
th a strong (not FCC approved) receiver.
>> >>
>> >> WiFi hotspots don't have strong identity or a guaranteed position, so=
they can't be trusted for location.
>> >>
>> >> e
>> >>
>> >> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike@plan99.net> wrote:
>> >>
>> >>>> This sounds horrible. You could basically monitor anyone with a wal=
let in a highly populated area and track them super easily by doing facial =
recognition.
>> >>>
>> >>> We're talking about BLE, still? The radio tech that runs in the so c=
alled "junk bands" because propagation is so poor?
>> >>>
>> >>> My watch loses its connection to my phone if I just put it down and =
walk around my apartment. I'm all for reasonable paranoia, but Bluetooth is=
n't going to be enabling mass surveillance any time soon. It barely goes th=
rough air, let alone walls.
>> >>>
>> >>> Anyway, whatever. I'm just bouncing around ideas for faster user int=
erfaces. You could always switch it off or set it to be triggered by the pr=
esence of particular wifi hotspots, if you don't mind an initial bit of set=
up.
>> >>>
>> >>> Back on topic - the debate is interesting, but I think to get this t=
o the stage of being a BIP we'd need at least another wallet to implement i=
t? Then I guess a BIP would be useful regardless of the design issues. The =
prefix matching still feels flaky to me but it's hard to know if you could =
really swipe payments out of the air in practice, without actually trying i=
t.
>> >
>
>> ------------------------------------------------------------------------=
------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is =
your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take=
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
>
>
> -------------------------------------------------------------------------=
-----
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is y=
our
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take =
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
|
