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
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Z4rtt-0004YW-S9
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 14:31:41 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.176 as permitted sender)
client-ip=209.85.160.176; envelope-from=pieter.wuille@gmail.com;
helo=mail-yk0-f176.google.com;
Received: from mail-yk0-f176.google.com ([209.85.160.176])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4rts-0006hi-3o
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 14:31:41 +0000
Received: by ykar6 with SMTP id r6so14735162yka.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Jun 2015 07:31:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.57.198 with SMTP id 189mr792746ykz.35.1434465094599;
Tue, 16 Jun 2015 07:31:34 -0700 (PDT)
Received: by 10.37.93.67 with HTTP; Tue, 16 Jun 2015 07:31:34 -0700 (PDT)
In-Reply-To: <CAPswA9yB3wfV1auXR=ggXjh+f1C3Qpkv8qP1miQwkc8R2_aBLg@mail.gmail.com>
References: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
<CAPg+sBjtovFpLoibpVGLsNJXexBcoiYzjrvctraXntCUZBJsGg@mail.gmail.com>
<CAPswA9zhB4GV=JJ28RRLFNrkVwExUv36zujmuAjwPd6rG6rvzQ@mail.gmail.com>
<CALJP9GCBJiofY7k2RJ460CuLuWQunHcx7EcLi1-d07v76Y-E2g@mail.gmail.com>
<CAPswA9wqdbU0z8ydBt+9M0iQX0VSi1ce=dg3fR2_2bx3-vEqzA@mail.gmail.com>
<CAPswA9z_xKY6v9=Ejh=01mZN0QCVo1e0RY1FTzXzS39i3tjgAw@mail.gmail.com>
<CAPswA9xk5QYAXxQ6ES3cnNPeB1FTiiSJgLahLEkSk4CLpoM_QQ@mail.gmail.com>
<CAPg+sBiWykR6RaHhbyYQbL=A5t1TmHgEmS_sC7jj9d3SUTMO9g@mail.gmail.com>
<CAPswA9zycU0pwZKaHU9J3Tvg=ovLJ8TZ9OH6ebTPONaRaiOE8g@mail.gmail.com>
<CAPg+sBhuth22+vAHyS2iwpze8X=-b2wJQ5s1z2FhZ1jsLXobgQ@mail.gmail.com>
<CAPswA9yB3wfV1auXR=ggXjh+f1C3Qpkv8qP1miQwkc8R2_aBLg@mail.gmail.com>
Date: Tue, 16 Jun 2015 16:31:34 +0200
Message-ID: <CAPg+sBjp-BmSXhanOuKE0DN1wdfVwCtFwiAbPse1GLxy3+L3nA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
Content-Type: multipart/alternative; boundary=001a1139441e680b040518a36eb3
X-Spam-Score: -0.6 (/)
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Z4rts-0006hi-3o
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP for Proof of Payment
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: Tue, 16 Jun 2015 14:31:41 -0000
--001a1139441e680b040518a36eb3
Content-Type: text/plain; charset=UTF-8
On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:
> 2015-06-15 12:00 GMT+02:00 Pieter Wuille <pieter.wuille@gmail.com>:
> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> someone with more insight into CoinJoin have some input?
>
Not really. The problem is that you assume a transaction corresponds to a
single payment. This is true for simple wallet use cases, but not
compatible with CoinJoin, or with systems that for example would want to
combine multiple payments in a single transaction.
> > Also, if I understand correctly, there is no commitment to anything
> you're
> > trying to say about the sender? So once I obtain a proof-of-payment from
> you
> > about something you paid, I can go claim that it's mine?
>
> I don't understand this. The pop includes a nonce randomly generated
> by the server. If you're very lucky, 1/(2^48) per try, you can reuse a
> pop.
>
>
I owe you an apology here, for judging based on the summary you posted
rather than reading the actual text.
48 bits seems low to me, but it does indeed solve the problem. Why not 128
or 256 bits?
> Why does anyone care who paid? This is like walking into a coffeshop,
> > noticing I don't have money with me, let me friend pay for me, and then
> have
> > the shop insist that I can't drink it because I'm not the buyer.
>
> If you pay as you use the service (ie pay for coffee upfront), there's
> no need for PoP. Please see the Motivation section. But you are right
> that you must have the wallet(s) that paid at hand when you issue a
> PoP.
>
> >
> > Track payments, don't try to assign identities to payers.
>
> Please elaborate, I don't understand what you mean here.
>
I think that is a mistake. You should not assume that the wallet who held
the coins is the payer/buyer. That's what I said earlier; you're implicitly
creating an identity (the one who holds these keys) based on the
transaction. This seems fundamentally wrong to me, and not necessary. The
receiver should not care who paid or how, he should care what was payed for.
The easiest solution to this IMHO would be an extension to the payment
protocol that gives you (or your wallet) a token in return for paying, and
that knowledge of that token is used to gain access to the services you
provide.
--
Pieter
--001a1139441e680b040518a36eb3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum <span dir=
=3D"ltr"><<a href=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@=
rosenbaum.se</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span cl=
ass=3D"">2015-06-15 12:00 GMT+02:00 Pieter Wuille <<a href=3D"mailto:pie=
ter.wuille@gmail.com">pieter.wuille@gmail.com</a>>:<br>
</span>I'm not sure if we will be able to support PoP with CoinJoin. Ma=
ybe<br>
someone with more insight into CoinJoin have some input?<br></blockquote><d=
iv><br></div><div>Not really. The problem is that you assume a transaction =
corresponds to a single payment. This is true for simple wallet use cases, =
but not compatible with CoinJoin, or with systems that for example would wa=
nt to combine multiple payments in a single transaction.<br></div><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=
=3D"">
> Also, if I understand correctly, there is no commitment to anything yo=
u're<br>
> trying to say about the sender? So once I obtain a proof-of-payment fr=
om you<br>
> about something you paid, I can go claim that it's mine?<br>
<br>
</span>I don't understand this. The pop includes a nonce randomly gener=
ated<br>
by the server. If you're very lucky, 1/(2^48) per try, you can reuse a<=
br>
pop.<br>
<span class=3D""><br></span></blockquote><div>=C2=A0<br></div><div>I owe yo=
u an apology here, for judging based on the summary you posted rather than =
reading the actual text.<br><br></div><div>48 bits seems low to me, but it =
does indeed solve the problem. Why not 128 or 256 bits?<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><span class=3D"">
> Why does anyone care who paid? This is like walking into a coffeshop,<=
br>
> noticing I don't have money with me, let me friend pay for me, and=
then have<br>
> the shop insist that I can't drink it because I'm not the buye=
r.<br>
<br>
</span>If you pay as you use the service (ie pay for coffee upfront), there=
's<br>
no need for PoP. Please see the Motivation section. But you are right<br>
that you must have the wallet(s) that paid at hand when you issue a<br>
PoP.<br>
<span class=3D""><br>
><br>
> Track payments, don't try to assign identities to payers.<br>
<br>
</span>Please elaborate, I don't understand what you mean here.<br></bl=
ockquote><div><br>I think that is a mistake. You should not assume that the=
wallet who=20
held the coins is the payer/buyer. That's what I said earlier; you'=
re=20
implicitly creating an identity (the one who holds these keys) based on=20
the transaction. This seems fundamentally wrong to me, and not necessary. T=
he receiver should not care who paid or how, he should care=20
what was payed for.<br>=C2=A0<br></div><div>The easiest solution to this IM=
HO would be an extension to the payment protocol that gives you (or your wa=
llet) a token in return for paying, and that knowledge of that token is use=
d to gain access to the services you provide.<br><br>-- <br></div><div>Piet=
er<br><br></div></div></div></div>
--001a1139441e680b040518a36eb3--
|
