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)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Instant / contactless payments
Precedence: list

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