From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1WLUrx-0002PV-OB for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 09:45:37 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.172 as permitted sender) client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f172.google.com; Received: from mail-ob0-f172.google.com ([209.85.214.172]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WLUrw-0004Aa-LI for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 09:45:37 +0000 Received: by mail-ob0-f172.google.com with SMTP id wm4so2301328obc.3 for ; Thu, 06 Mar 2014 01:45:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.160.102 with SMTP id xj6mr9075486obb.19.1394099131343; Thu, 06 Mar 2014 01:45:31 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Thu, 6 Mar 2014 01:45:31 -0800 (PST) Date: Thu, 6 Mar 2014 10:45:31 +0100 X-Google-Sender-Auth: dUhNQCgcgnBbjTf00to4xAjMqmQ Message-ID: From: Mike Hearn To: Bitcoin Dev Content-Type: multipart/alternative; boundary=bcaec5396c16816af004f3ecff72 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: 1WLUrw-0004Aa-LI Subject: [Bitcoin-development] Instant / contactless payments X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:45:38 -0000 --bcaec5396c16816af004f3ecff72 Content-Type: text/plain; charset=UTF-8 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. The other is that obviously the payment device has to decide to sign the transaction without any user interaction, i.e. the payment is at low risk of being unintentional. If you nail this it can be used for one-click web payments too. Andreas already did some work on embedding full blown payment requests into an NFC tag, but I think we need to switch this to being a packet based protocol (via ISO-DEP), otherwise you can't submit the Payment/tx messages back via NFC as well. This isn't a very complicated task and would make a fun project for a newbie who has Android and knows some Java. The resulting ISO-DEP protocol can be turned into a BIP without too much trouble. The risk analysis is the more complicated part. The real value Visa/MasterCard provide with NFC payments is not so much the tech (the clever part is the batteryless nature of the cards rather than the crypto/comms), but the fact that merchants are all verified and can be fined or evicted if they abuse the system and try to steal money. Bitcoin doesn't have anything like that. I think we have a few options to make it safe: 1) Require some very lightweight user confirmation, like pressing the power button to reach the lock screen and only allowing small payments. The combination of physical proximity and pressing the power button is probably good enough for now to avoid problems. Someone should try it out and see how it feels. 2) Have some kind of semi-centralised merchant verification/approval programs, like what the card networks do. The easiest way to start would be to piggyback on the work BitPay/Coinbase do and just auto-sign if payment amount is I just did my first contactless nfc payment with a MasterC= ard. It worked very well and was quite delightful - definitely want to be d= oing 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 her= e 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 paymen= t needs two things to work: one is a VERY fast, low latency communication b= etween 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.

The other is that obviously the payment device has to d= ecide to sign the transaction without any user interaction, i.e. the paymen= t is at low risk of being unintentional. If you nail this it can be used fo= r one-click web payments too.

Andreas already did some work on embedding full blown p= ayment requests into an NFC tag, but I think we need to switch this to bein= g a packet based protocol (via ISO-DEP), otherwise you can't submit the= Payment/tx messages back via NFC as well. This isn't a very complicate= d task and would make a fun project for a newbie who has Android and knows = some Java. The resulting ISO-DEP protocol can be turned into a BIP without = too much trouble.

The risk analysis is the more complicated part. The rea= l value Visa/MasterCard provide with NFC payments is not so much the tech (= the clever part is the batteryless nature of the cards rather than the cryp= to/comms), but the fact that merchants are all verified and can be fined or= evicted if they abuse the system and try to steal money. Bitcoin doesn'= ;t have anything like that.

I think we have a few options to make it safe:

1) Require some very lightweight user confirmation, like p= ressing the power button to reach the lock screen and only allowing small p= ayments. The combination of physical proximity and pressing the power butto= n is probably good enough for now to avoid problems. Someone should try it = out and see how it feels.

2) Have some kind of semi-centralised merchant verifica= tion/approval programs, like what the card networks do. The easiest way to = start would be to piggyback on the work BitPay/Coinbase do and just auto-si= gn if payment amount is <X mBTC and the payment is via one of these proc= essors. But this is hardly in the spirit of Bitcoin and is generally unsati= sfying.

3) Have some kind of decentralised reputation network. = I spent some time thinking about this, but it rapidly became very complicat= ed and feels like an entirely separate project that should stand alone from= Bitcoin itself. Perhaps rather than try to make a global system, social da= ta could be exchanged (using some fancy privacy preserving protocols?) so i= f your friends have decided to trust seller X, your phone automatically tru= sts them too.

4) Have the touch trigger a delayed payment and the pho= ne tries to attract attention to itself so the user can cancel. This way if= someone tries to swipe money out of your pocket by getting up close on a s= ubway or something, you have a chance to cancel. But it's quite hard fo= r a small device to reliably attract attention quickly and it opens up the = merchant to fraud where the user pays, leaves and then cancels the payment.= Especially it'd be useless for things like mass transit. So I think su= ch a system would have to be opt-in by the seller.

5) A combination of all the above.

=
To get the very fast light feel the actual contact period has to be qu= ite short, so I bet we'd need to optimise the bootup process of the And= roid wallet app. Right now it does slow things like deserialising giant pro= tocol buffers and is just generally not optimised for startup time. Loading= the wallet, reading the payment request over NFC, checking the cert signat= ures, making the trust decision, calculating a transaction, signing it, sen= ding it back to the recipient all in under 400 msec would be a tough (but f= un) programming challenge. Some of the steps can be parallelised and modern= phones are mostly multicore.
--bcaec5396c16816af004f3ecff72--