path: root/ea/af3ebabb18a2519ebed6c49b242638a40df763

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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <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 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 <X mBTC and the payment is via one of these processors. But this
is hardly in the spirit of Bitcoin and is generally unsatisfying.

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

4) Have the touch trigger a delayed payment and the phone 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 subway or
something, you have a chance to cancel. But it's quite hard for 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 such 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 quite
short, 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.

--bcaec5396c16816af004f3ecff72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">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&#39;s involved.<div>
<br></div><div>There are two aspects that can be implemented independently =
of each other:</div><div><br></div><div>1) The physical/NFC layer.</div><di=
v>2) The risk analysis layer.</div><div><br></div><div>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&#39;t find=
 actual latency specs yet but it felt like using an Oyster card, which aims=
 for &lt;400msec.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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&#39;t submit the=
 Payment/tx messages back via NFC as well. This isn&#39;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.</div>
<div><br></div><div>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&#39=
;t have anything like that.</div>
<div><br></div><div>I think we have a few options to make it safe:</div><di=
v><br></div><div>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.</div>
<div><br></div><div>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 &lt;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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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&#39;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&#39;d be useless for things like mass transit. So I think su=
ch a system would have to be opt-in by the seller.</div>
<div><br></div><div>5) A combination of all the above.</div><div><br></div>=
<div>To get the very fast light feel the actual contact period has to be qu=
ite short, so I bet we&#39;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.</div>
</div>

--bcaec5396c16816af004f3ecff72--