public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Troy Benjegerdes <hozer@hozed.org>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Instant / contactless payments
Date: Fri, 7 Mar 2014 13:08:04 -0600	[thread overview]
Message-ID: <20140307190804.GV3180@nl.grid.coop> (raw)
In-Reply-To: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>

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




  parent reply	other threads:[~2014-03-07 19:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06  9:45 [Bitcoin-development] Instant / contactless payments Mike Hearn
2014-03-06 11:26 ` Andreas Schildbach
2014-03-06 13:44   ` Mike Hearn
2014-03-06 14:51     ` Andreas Schildbach
2014-03-06 16:55       ` [Bitcoin-development] Instant / contactless payments, IsoDep Andreas Schildbach
2014-03-06 17:00         ` Mike Hearn
2014-03-07  8:45           ` Andreas Schildbach
2014-03-07  9:26   ` [Bitcoin-development] Instant / contactless payments Johannes Zweng
2014-03-07 10:00     ` Mike Hearn
2014-03-07 10:23     ` Andreas Schildbach
2014-03-07 11:01       ` Mike Hearn
2014-03-07 12:00       ` Johannes Zweng
2014-03-06 14:20 ` Brooks Boyd
2014-03-06 17:07   ` Mike Hearn
2014-03-06 18:08     ` Brooks Boyd
2014-03-06 18:12       ` Mike Hearn
2014-03-06 18:20         ` Brooks Boyd
2014-03-06 18:24           ` Mike Hearn
2014-03-07 18:07   ` Joel Kaartinen
2014-03-06 14:39 ` Alex Kotenko
2014-03-06 16:46   ` Andreas Schildbach
2014-03-06 16:52     ` Mike Hearn
2014-03-06 18:03     ` Alex Kotenko
2014-03-07  8:59       ` Andreas Schildbach
2014-03-06 17:03   ` Mike Hearn
2014-03-06 18:49     ` Alex Kotenko
2014-03-08  8:52   ` Jan Vornberger
2014-03-10 15:09     ` Alex Kotenko
2014-03-10 19:28       ` Andreas Schildbach
2014-03-10 19:47         ` Alex Kotenko
2014-03-07 19:08 ` Troy Benjegerdes [this message]
2014-03-10 16:04 ` Mike Hearn
2014-03-10 16:14   ` Jean-Paul Kogelman
2014-03-10 16:27     ` Alex Kotenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140307190804.GV3180@nl.grid.coop \
    --to=hozer@hozed.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox