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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WQY2F-0004tC-0M for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 08:09:07 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WQY2D-00018U-VY
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 08:09:06 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WQY26-0002IY-7X for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 09:08:58 +0100
Received: from f052022250.adsl.alicedsl.de ([78.52.22.250])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Mar 2014 09:08:58 +0100
Received: from andreas by f052022250.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Mar 2014 09:08:58 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Thu, 20 Mar 2014 09:08:45 +0100
Message-ID: <lge7lv$3mf$1@ger.gmane.org>
References: <lc5hmg$1jh$1@ger.gmane.org>
<leuunm$tjk$1@ger.gmane.org> <CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
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: f052022250.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
In-Reply-To: <CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
X-Enigmail-Version: 1.5.2
X-Spam-Score: -0.4 (/)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1WQY2D-00018U-VY
Subject: Re: [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: Thu, 20 Mar 2014 08:09:07 -0000
On 03/20/2014 03:22 AM, Alex Kotenko wrote:
> Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
> need to still be able to use it for backwards compatibility. But at the
> same time I want to be able to support BIP70. And also I want to avoid
> using external servers, the concept of my POS is that everything is
> happening between just payer's phone and payee's POS device. This means
> that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
We could use Bluetooth in the "r" parameter, not unlike we use Bluetooth
in the payment_url. However, since multiple devices could access your
machine at the same time, we need some for of adressibility of different
payment requests. Something like
"bt:<btmac>-<random_id_of_payment_request>".
> You're also offering an option to include Base43 encoded PR body right
> inside the Bitcoin URI, but in a way that is not backwards compatible
> with BIP21.
Well, do we need to be compatible? If the dev community decides Base43
PR QR's (or whatever other self-contained format) is the way to go, we
just implement, roll it out and use it.
> I understand your intention behind base43 encoding and noncompatible URI
> - you want to make most possible use of QR codes. But I wonder - did you
> compare this base43 to base64 encoded request in a binary QR code
> format? How much do we actually win in total bytes capacity at a price
> of noncompatibility and increased complexity?
Alphanumeric QR codes have an alphabet of 45 chars, of which I am using
43. I skipped Space and '%' because they're not allowed in URIs. When I
invented the Base43 format back in 2011, wanted it to be URI compatible
so we can use the Android intent dispatcher.
If we let go of the URI requirement, we can use binary QR codes as well.
This means users will always have to manually start their Bitcoin app
first. (Also, there is an implementation issue with the ZXing scanner
I'm using, it returns Strings rather than a byte array so it will choke
on \0 characters.)
> And also maybe we can extend BIP72 to include encoded payment request in
> the URL directly in a backwards compatible way?
I took this into consideration. It would be space inefficient.
The Base58-encoded address from BIP21 forces the QR code into binary
mode. Still you can't encode the payment request extension (probably an
URL parameter) as binary because it needs to stay compatible to the URI
standard (RFC 3986). You could use one of the Base64 variants for the PR
in this case, but still it would be inefficient.
|
