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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WLYbB-00010y-5q
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 13:44:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WLYbA-0004gH-8l
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 13:44:33 +0000
Received: by mail-ob0-f175.google.com with SMTP id uy5so2544121obc.20
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Mar 2014 05:44:27 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.98.73 with SMTP id eg9mr450725oeb.81.1394113466896; Thu,
06 Mar 2014 05:44:26 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 6 Mar 2014 05:44:26 -0800 (PST)
In-Reply-To: <lf9m0e$q7t$1@ger.gmane.org>
References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
<lf9m0e$q7t$1@ger.gmane.org>
Date: Thu, 6 Mar 2014 14:44:26 +0100
X-Google-Sender-Auth: Zzf-yEn8_RshRScTXqmjd7jELJU
Message-ID: <CANEZrP2GbnsqQANGKMW_5FAugppGJEksaB=Tf8Xu1nRLy3z9yg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=089e0139fc60f9a02d04f3f0553e
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: 1WLYbA-0004gH-8l
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Instant / contactless payments
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, 06 Mar 2014 13:44:33 -0000
--089e0139fc60f9a02d04f3f0553e
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 6, 2014 at 12:26 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:
> I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
> up the phone the connection breaks.
If the phone isn't willing to immediately authorise then it'd have to fall
back to HTTPS or Bluetooth as normal.
> Besides, how do you plan to risk-analyse the memo field?
>
I guess only the amount and destination are relevant for risk analysis.
> It's already very short if you can do without Android Beam, e.g. on
> Android 2.3.
I think IsoDep based protocols must bypass Beam - when I scan my e-passport
there's no beam animation.
> The most obvious optimization to speed up signature checking is to make
> it lazy. The user can already inspect the payment while signatures are
> being checked.
Well, for <400msec there can't be any user interaction. But checking
signatures on the payment request and constructing and signing the inputs
can all be done in parallel - you should be able to max out every core, at
least for a brief moment.
> Even the current ~10 second roundtrip is a huge improvement to the
> status quo. I recently tried to buy a subway ticket and it took me 7
> full minutes (just for the payment process)!
Then that subway kind of sucks ;) Have you been to London and used Oyster?
I think the capital wouldn't work at all without the low latency Oyster
cards. The tube would have stopped scaling some time ago.
--089e0139fc60f9a02d04f3f0553e
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">On T=
hu, Mar 6, 2014 at 12:26 PM, Andreas Schildbach <span dir=3D"ltr"><<a hr=
ef=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildbach.de=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I'm not sure if iso-dep is the way to go=
here. Afaik as soon as you pick<br>
up the phone the connection breaks.</blockquote><div><br></div><div>If the =
phone isn't willing to immediately authorise then it'd have to fall=
back to HTTPS or Bluetooth as normal.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
Besides, how do you plan to risk-analyse the memo field?<br></blockquote><d=
iv><br></div><div>I guess only the amount and destination are relevant for =
risk analysis.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">It's already very short if you can do without Android B=
eam, e.g. on<br></div>
Android 2.3.</blockquote><div><br></div><div>I think IsoDep based protocols=
must bypass Beam - when I scan my e-passport there's no beam animation=
.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The most obvious optimization to speed up signature checking is to make<br>
it lazy. The user can already inspect the payment while signatures are<br>
being checked.</blockquote><div><br></div><div>Well, for <400msec there =
can't be any user interaction. But checking signatures on the payment r=
equest and constructing and signing the inputs can all be done in parallel =
- you should be able to max out every core, at least for a brief moment.</d=
iv>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Even the current ~10 second=
roundtrip is a huge improvement to the<br>
status quo. I recently tried to buy a subway ticket and it took me 7<br>
full minutes (just for the payment process)!</blockquote><div><br></div><di=
v>Then that subway kind of sucks ;) Have you been to London and used Oyster=
? I think the capital wouldn't work at all without the low latency Oyst=
er cards. The tube would have stopped scaling some time ago.=C2=A0</div>
</div></div></div>
--089e0139fc60f9a02d04f3f0553e--
|
