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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WLWRj-0005n4-S1 for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 11:26:39 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WLWRi-0007Dq-HQ
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 11:26:39 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WLWRb-0007c0-Pb for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 12:26:31 +0100
Received: from f052204080.adsl.alicedsl.de ([78.52.204.80])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Mar 2014 12:26:31 +0100
Received: from andreas by f052204080.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Mar 2014 12:26:31 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Thu, 06 Mar 2014 12:26:20 +0100
Message-ID: <lf9m0e$q7t$1@ger.gmane.org>
References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f052204080.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
In-Reply-To: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1WLWRi-0007Dq-HQ
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 11:26:40 -0000
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. It's ok if some people decide to let
the app do risk analysis, but you cannot force it onto users by picking
a protocol that cannot deal with manual verification. Users should
always have the choice to verify their payment without time pressure and
by holding the device of their choice at their individual viewing distance.
Besides, how do you plan to risk-analyse the memo field?
In current phone implementations, the screen must be on already for NFC
to be active. Also it must be unlocked, although I certainly hope future
OSes will allow payment apps on the lock screen, just like they allow
music players.
> To get the very fast light feel the actual contact period has to be
> quite short, so I bet we'd need to optimise the bootup process of the
> Android wallet app.
It's already very short if you can do without Android Beam, e.g. on
Android 2.3. I'd say <200 ms for an BIP21 payment request. Bootup of the
app and everything else happens after -- no need to continue contact.
Indeed most of the bootup time goes into loading complex wallets. Our
long standing plans to clean up the wallet and archieve transactions
should help. Also, if Bitcoin catches on the app will just stay in memory.
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. Even transaction signing could already happen in advance,
if it can be made sure that no signed transaction "escapes" the dialog
without the users consent.
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)!
|
