From: Andreas Schildbach <andreas@schildbach•de>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Date: Mon, 27 Jan 2014 12:59:25 +0100 [thread overview]
Message-ID: <lc5hmg$1jh$1@ger.gmane.org> (raw)
As promised I'd like to present my work done on leveraging the payment
protocol for face-to-face payments. The general assumption is that
individuals don't own X.509 certificates. Their devices may be only
badly connected to the internet or in some cases not at all. I've
implemented a prototype on a branch of Bitcoin Wallet. It is using
bitcoinj 0.11 (not released).
https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol
TAP TO PAY
First I looked at the NFC tap-to-pay usecase. The way it works as
currently rolled out: A BIP21 URL is published using an NDEF URI
message. The URL is supplemented by a Bluetooth MAC address that can be
connected in order to finish the payment. Once connected, a very simple
custom protocol transmits the signed transaction(s) in
bitcoin-serialized form to the payee, who replies with an ack or nack.
The way I prototyped it to work in future: Instead of the BIP21 URL a
BIP70 payment request is published using an NDEF MIME message (mime-type
as per BIP71). The paymentUrl field can (and in the face-to-face case
should) contain a Bluetooth URL which contains the MAC address of the
payee. Because I could not find any standard for Bluetooth URLs, I made
up my own: "bt:112233445566" means MAC address 11:22:33:44:55:66. Once
connected, Payment message and PaymentACK reply are used to finish the
payment. Since Bluetooth sockets are streams, I had to use the delimited
variant of the protobufs for Payment and PaymentACK messages. This
prepends them with a VARINT containing the message length.
All of the above should be easy to migrate. NFC implementations are
rare, and the current Bluetooth protocol is implemented only by Bitcoin
Wallet afaik. Fallbacks are provided where necessary.
In future, I'd like to add encryption to the Bluetooth connection, maybe
using SSL and some DH key exchange.
SCAN TO PAY
For scan-to-pay, the current landscape looks different. I assume at
least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
into a QR-code. Nevertheless, I tried to encode a payment request into
the bitcoin URL. I used my existing work on encoding transactions into
QR-codes. Steps to encode:
1. The payment request is protobuf-serialized. For a simple payment
request, this results in only ~50 bytes thanks to the efficiency of
protobuf.
2. The bytes are encoded using "Base43", which is the same as
Base64/Base58, but its alphabet consists of the characters allowed in
so-called "alphanumeric" QR-codes, minus the characters not allowed in URLs.
3. The resulting string is prefixed by "BITCOIN:"
4. All of that goes into a QR-code, and because it only contains
"alphanumeric" characters, it will produce a very efficient code. For
simple payment requests, I could not notice any difference in scanning
difficulty.
There are some limitations however:
- Obviously such QR-encoded payment requests cannot grow in size as much
as using other media. In particular, I expect PKI signed requests are
out of question. However, in face to face payments the value of a sig
based on PKI is highly questionable, and the fact the sig cannot be
verified without TCP connectivity doesn't help. There should be some
headroom for multiple-output requests and moderately more complex
scripts though.
- I chose to re-use the "bitcoin:" URL scheme, because it's already
whitelisted in web browsers, QR-code scanners and so on. In order to
differentiate "payment requests URLs" from BIP21 URLs, I test for
uri.startsWith("BITCOIN:") because you'll get letters in all-caps from
alphanumeric QR-codes. I will investigate into a better solution.
- Due to wide deployment of BIP21 QR-codes, migration needs to happen in
distinct phases. Ability to parse "payment protocol URLs" comes first,
default to presenting them to users has to come (much) later.
CLICK TO PAY
Finally this is the usecase the payment protocol was invented for and
it's not face-to-face. I don't have much to add, just one thing. As a
byproduct of the above, "payment protocol URLs" can be used for links
published on web pages as well. This might provide a nice replacement
for the imho rather ugly BIP72 specification once the payment protocol
is widely deployed.
Open for discussion.
next reply other threads:[~2014-01-27 11:59 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 11:59 Andreas Schildbach [this message]
2014-01-27 13:11 ` Mike Hearn
2014-01-27 18:18 ` Andreas Schildbach
2014-01-27 18:34 ` Mike Hearn
2014-01-27 20:53 ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach
2014-01-27 21:47 ` Mike Hearn
2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman
2014-01-27 17:39 ` Andreas Schildbach
2014-01-27 18:18 ` Jeremy Spilman
2014-01-27 20:34 ` Roy Badami
2014-01-29 14:57 ` Christophe Biocca
2014-01-30 10:46 ` Andreas Schildbach
2014-01-30 10:50 ` Mike Hearn
2014-02-07 23:15 ` Andreas Schildbach
2014-03-02 9:47 ` Andreas Schildbach
2014-03-02 11:50 ` Mike Hearn
2014-03-20 2:22 ` Alex Kotenko
2014-03-20 3:31 ` Jeff Garzik
2014-03-20 8:09 ` Andreas Schildbach
2014-03-20 10:36 ` Mike Hearn
2014-03-20 12:12 ` Adam Back
2014-03-20 12:20 ` Mike Hearn
2014-03-20 17:31 ` Jeff Garzik
2014-03-20 17:42 ` Alex Kotenko
2014-03-20 18:01 ` Jeff Garzik
2014-03-21 10:28 ` Andreas Schildbach
2014-03-21 13:59 ` Alex Kotenko
2014-03-22 16:35 ` Jeff Garzik
2014-03-22 16:45 ` Mike Hearn
2014-03-22 16:55 ` Mark Friedenbach
2014-03-22 17:24 ` Jeff Garzik
2014-03-22 17:30 ` Mike Hearn
2014-03-23 3:47 ` Alex Kotenko
2014-03-21 10:25 ` Andreas Schildbach
2014-03-21 10:59 ` Adam Back
2014-03-21 11:08 ` Mike Hearn
2014-03-21 11:33 ` Mike Hearn
2014-03-21 12:25 ` Adam Back
2014-03-21 13:07 ` Mike Hearn
2014-03-20 18:20 ` Alex Kotenko
2014-03-20 18:31 ` Mike Hearn
2014-03-20 18:50 ` Alex Kotenko
2014-03-20 21:52 ` Roy Badami
2014-03-20 23:02 ` Mike Hearn
2014-03-26 22:48 ` Roy Badami
2014-03-26 22:56 ` Mike Hearn
2014-03-26 23:20 ` Andreas Schildbach
2014-03-27 10:08 ` Mike Hearn
2014-03-27 13:31 ` vv01f
2014-06-30 19:26 ` Alex Kotenko
2014-07-01 8:18 ` Mike Hearn
2014-07-01 9:48 ` Andreas Schildbach
2014-07-01 10:42 ` Michael Wozniak
2014-07-01 13:03 ` Alex Kotenko
2014-07-01 14:59 ` Andreas Schildbach
2014-07-01 15:07 ` Michael Wozniak
2014-07-01 15:39 ` Andreas Schildbach
2014-07-01 17:18 ` Alex Kotenko
2014-07-01 17:59 ` Mike Hearn
2014-07-02 8:49 ` Alex Kotenko
2014-03-21 10:43 ` Andreas Schildbach
2014-03-20 8:08 ` Andreas Schildbach
2014-03-20 16:14 ` Alex Kotenko
2014-03-21 9:47 ` Andreas Schildbach
2014-03-21 13:54 ` Alex Kotenko
2014-03-21 14:51 ` Andreas Schildbach
2014-03-21 15:38 ` Alex Kotenko
2014-03-21 15:20 ` Andreas Schildbach
2014-03-21 15:24 ` Mike Hearn
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='lc5hmg$1jh$1@ger.gmane.org' \
--to=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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