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
162
163
164
165
166
167
168
169
170
171
172
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1W7qlT-0003yu-Ub for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 18:18:31 +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 1W7qlS-0007FT-NE
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 18:18:31 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1W7qlL-0001fz-TQ for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 19:18:23 +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 19:18:23 +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 19:18:23 +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 19:18:11 +0100
Message-ID: <lc67sl$h3$1@ger.gmane.org>
References: <lc5hmg$1jh$1@ger.gmane.org>
<CANEZrP3POX5SACS18_rrQxx=mzmthrM418zmd8Z7-5CBNFSW4Q@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: f053014231.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <CANEZrP3POX5SACS18_rrQxx=mzmthrM418zmd8Z7-5CBNFSW4Q@mail.gmail.com>
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: 1W7qlS-0007FT-NE
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: Mon, 27 Jan 2014 18:18:32 -0000
On 01/27/2014 02:11 PM, Mike Hearn wrote:
> I would like to see Bluetooth continue to work for scan-to-pay even in
> the signed case. So for this reason the current approach with a BTMAC
> parameter in the Bitcoin URI seems to work universally across NFC tags
> and QR codes, and would allow download of a signed PaymentRequest even
> in the case where a QR code is used.
I'm not saying I'm against signed payment requests, but unfortunately
they are just too big for QR-codes. Then again, QR-codes *can* take up
to 2 KB. How big would a very basic trust chain plus signature be?
> Because a Bitcoin URI already contains a public key (hash), re-using
> that to establish an encrypted/authd connection on top of an insecure
> RFCOMM socket would seem to be relatively straightforward.
I was under the impression that addresses will go away. Can you
elaborate on the mechanism?
> 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.
>
> Just a correction here - the reason signed payment requests are "large"
> (about 4000 bytes) is exactly because they *can* be verified offline,
> i.e. by a Trezor. The signed payment request contains all the data
> needed to establish its authenticity, including certificates and the
> signature itself. No TCP connection is needed.
Ok, that's good news (to me). However, you are going to manage trust
stores (adding and revoking) without TCP?
> For face to face payments, I think signing is still useful. For one, we
> want to keep the distinction between "merchant" and "user" as blurry and
> indistinct as possible. A strong separation between merchants and
> consumers is one of the many bad things about the credit card system.
Ack.
> Whilst initially we'd expect the payment protocol to be used by online
> webshops, in future it could be used by little corner shops, children's
> lemonade stands and so on.
Well I'm thinking the other way round. Use Bitcoin where its already
used today -- face to face.
> you probably still would like a receipt if you buy
> something from a local market trader.
Yes, but where is the problem?
> Another use case - we heard a story about a restaurant owner who
> accepted Bitcoin. He printed a static bitcoin URI onto a QR code on the
> menu. A month or two later he discovered one of his waiters had
> re-printed the menus with his own QR code! The people thought they had
> been paying for the meal, and in fact it went right into the pocket of
> the waiter.
Sad story, but it's really a special case. Using a printed QR-code is
clearly the wrong tool for his task, for several reasons.
And again, how is he going to provide the payment request to the payer
without TCP?
> As to how it works, well, that's not hard. Comodo give away free email
> address certs with a few mouse clicks, it's no harder than signing up
> for a website.
We don't want to force people to sign up anywhere. Bitcoin is instant-on.
> - I chose to re-use the "bitcoin:" URL scheme
>
> Other wallets won't know what to do with it and would yield a strange
> error message.
Which is why I said we need some transition time.
> Rather than pack a file into a URL, if you don't want to
> use the current r= extension it's better for apps to just register to
> handle .bitcoinpaymentrequest files / the right MIME type. Downloading
> it and opening it would do the right thing automatically.
That's a good point. I'll implement this asap.
> Remember BIP 73 also! It says that with the apps built-in QR scanner, if
> you scan an HTTP[S] URI, you should try downloading it with a magic
> header. That way you can get a payment request file out of the server.
> Without the magic header (i.e. a normal generic barcode scanner app) it
> would open a web page containing a bitcoin URI clickable link.
Interesting, did not know about this BIP. However I don't understand the
usecase. Its not like my browsers always display QR-codes with URL of
the page being shown. And if the page in question bothers to show a QR
code, it could just as well also link to a payment request resource (as
suggested above).
|
