1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1W7kqx-0001ZQ-Sw for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 11:59:47 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1W7kqw-0003Mt-71
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 11:59:47 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1W7kql-0006C7-R6 for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 12:59:35 +0100
Received: from f053014231.adsl.alicedsl.de ([78.53.14.231])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Mon, 27 Jan 2014 12:59:35 +0100
Received: from andreas by f053014231.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Mon, 27 Jan 2014 12:59:35 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 27 Jan 2014 12:59:25 +0100
Message-ID: <lc5hmg$1jh$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f053014231.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
X-Spam-Score: -0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 SPF_PASS SPF: sender matches SPF record
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1W7kqw-0003Mt-71
Subject: [Bitcoin-development] Payment Protocol for Face-to-face 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: Mon, 27 Jan 2014 11:59:48 -0000
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.
|
