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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hozer@grid.coop>) id 1WM081-00008M-MT
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Mar 2014 19:08:17 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WM07w-0002Kw-5F for bitcoin-development@lists.sourceforge.net;
Fri, 07 Mar 2014 19:08:17 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Fri, 07 Mar 2014 13:08:04 -0600
id 000000000006A32E.00000000531A1914.000052C6
Date: Fri, 7 Mar 2014 13:08:04 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140307190804.GV3180@nl.grid.coop>
References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WM07w-0002Kw-5F
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: Fri, 07 Mar 2014 19:08:17 -0000
On Thu, Mar 06, 2014 at 10:45:31AM +0100, Mike Hearn wrote:
> I just did my first contactless nfc payment with a MasterCard. It worked
> very well and was quite delightful - definitely want to be doing more of
> these in future. I think people will come to expect this kind of
> no-friction payment experience and Bitcoin will need to match it, so here
> are some notes on what's involved.
>
> There are two aspects that can be implemented independently of each other:
>
> 1) The physical/NFC layer.
> 2) The risk analysis layer.
>
> A contactless payment needs two things to work: one is a VERY fast, low
> latency communication between payment device (phone in our case) and
> terminal. I couldn't find actual latency specs yet but it felt like using
> an Oyster card, which aims for <400msec.
What matters more than the latency is the *variability*. I would spec this
system for no less than 200ms, and no more than 250ms to be 'standard'.
> ..... so I bet we'd need to optimise the bootup process of the Android
> wallet app. Right now it does slow things like deserialising giant protocol
> buffers and is just generally not optimised for startup time. Loading the
> wallet, reading the payment request over NFC, checking the cert signatures,
> making the trust decision, calculating a transaction, signing it, sending
> it back to the recipient all in under 400 msec would be a tough (but fun)
> programming challenge. Some of the steps can be parallelised and modern
> phones are mostly multicore.
If you have to invoke a java/ios/etc app you are never going to be consistent,
however if you have a GPL linux kernel module (like I proposed for my still
hypothetical 7coin), you should have no trouble meeting those specs.
I'd like to be able to load my java app, tell it to put $50 on my 'instant'/nfc
wallet, and then let the kernel module spend out the $50 whenever the phone
gets swiped by somehting.
If you do this right, every device has a well-known payment address for it's
'instant' wallet, and it should be trivial for merchants to just look at the
blockchain and confirm the instant wallet has a sufficient balance to cover
the transaction.
One more comment... having a bitcoin payment application 'check certs' seems
like a great way to ensure that Visa maintains their market share.
If it's my phone, and I press the hardware payment button, and I only put
$50 on it, I frankly don't care if there's a cert or not. The last thing I
want is a 'certificate validation error' when I'm trying to buy a soda.
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
|
