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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YWWDh-0003Ho-97
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 20:30:09 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.44 as permitted sender)
client-ip=74.125.82.44; envelope-from=natanael.l@gmail.com;
helo=mail-wg0-f44.google.com;
Received: from mail-wg0-f44.google.com ([74.125.82.44])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YWWDf-0003s3-IM
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 20:30:09 +0000
Received: by wggx13 with SMTP id x13so25617510wgg.12
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Mar 2015 13:30:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.20.238 with SMTP id q14mr17223329wie.70.1426278601483;
Fri, 13 Mar 2015 13:30:01 -0700 (PDT)
Received: by 10.194.28.170 with HTTP; Fri, 13 Mar 2015 13:30:01 -0700 (PDT)
Received: by 10.194.28.170 with HTTP; Fri, 13 Mar 2015 13:30:01 -0700 (PDT)
In-Reply-To: <CAPswA9zzVDxW8_WXg5833r2Z4pxZOppYtNLHMQ=Nw-H72cMz7w@mail.gmail.com>
References: <CAPswA9zzVDxW8_WXg5833r2Z4pxZOppYtNLHMQ=Nw-H72cMz7w@mail.gmail.com>
Date: Fri, 13 Mar 2015 21:30:01 +0100
Message-ID: <CAAt2M1_PuqX3AarzT7qRowHLL5FQPFTAquxXXJ6Gz4FWK2OcHA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
Content-Type: multipart/alternative; boundary=bcaec53f3447646bc90511315db9
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
(natanael.l[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: 1YWWDf-0003s3-IM
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 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: Fri, 13 Mar 2015 20:30:09 -0000
--bcaec53f3447646bc90511315db9
Content-Type: text/plain; charset=UTF-8
Den 13 mar 2015 20:57 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:
>
> Hi all,
>
> I've been thinking about how a person can prove that she has made a
payment. I came up with an idea I call Proof of Payment (PoP) and I would
highly appreciate your comments. Has something like this been discussed
somewhere before?
>
> Use cases
>
> There are several scenarios in which it would be useful to prove that you
have paid for something. For example:
> A pre-paid hotel room where your PoP functions as a key to the door.
> An online video rental service where you pay for a video and watch it on
any device.
> An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During
this period you can upload new content to the sign whenever you like using
PoP.
> A lottery where all participants pay to the same address, and the winner
of the T-shirt is selected among the transactions to that address. You
exchange the T-shirt for a PoP for the winning transaction.
>
> These use cases can be achieved without any personal information (no
accounts, no e-mails, etc) being involved.
>
> Desirable properties:
> A PoP should be generated on demand.
> It should only be usable once to avoid issues due to theft.
> It should be able to create a PoP for any payment, regardless of script
type (P2SH, P2PKH, etc.).
Relevant: https://idemix.wordpress.com/
Anonymous Credentials allows an issuer to declare that you have certain
rights. For example, upon paying the service provider could issue you the
credentials for using their service up until a certain date.
When challenged to prove a statement about what credentials you have, you
can prove the fact that you've got the right credentials without revealing
anything else. You don't even reveal you're the same person as the last
time, if you prove the right to access a VPN multiple times there's no data
in it that links the different sessions together.
The main difference is that issuance of Anonymous Credentials aren't
"atomic" with the payment transactions, which can open up the risk for
certain types of dishonest behavior by the seller. You could however use a
proof in court of having paid for the credentials but not getting them
issued to you (maybe throw in usage of Factom to log issuance of
credentials?). With this construction of using both these methods, you add
stronger privacy for the usage of the services while simultaneously keeping
a degree of accountability for the payment.
The Zerocoin developers also got a paper on a blockchain version,
"Distributed Anonymous Credentials".
--bcaec53f3447646bc90511315db9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 13 mar 2015 20:57 skrev "Kalle Rosenbaum" <<a href=3D"mail=
to:kalle@rosenbaum.se">kalle@rosenbaum.se</a>>:<br>
><br>
> Hi all,<br>
><br>
> I've been thinking about how a person can prove that she has made =
a payment. I came up with an idea I call Proof of Payment (PoP) and I would=
highly appreciate your comments. Has something like this been discussed so=
mewhere before?<br>
><br>
> Use cases<br>
><br>
> There are several scenarios in which it would be useful to prove that =
you have paid for something. For example:<br>
> A pre-paid hotel room where your PoP functions as a key to the door.<b=
r>
> An online video rental service where you pay for a video and watch it =
on any device.<br>
> An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. Duri=
ng this period you can upload new content to the sign whenever you like usi=
ng PoP.<br>
> A lottery where all participants pay to the same address, and the winn=
er of the T-shirt is selected among the transactions to that address. You e=
xchange the T-shirt for a PoP for the winning transaction.<br>
><br>
> These use cases can be achieved without any personal information (no a=
ccounts, no e-mails, etc) being involved.<br>
><br>
> Desirable properties:<br>
> A PoP should be generated on demand.<br>
> It should only be usable once to avoid issues due to theft.<br>
> It should be able to create a PoP for any payment, regardless of scrip=
t type (P2SH, P2PKH, etc.).</p>
<p dir=3D"ltr">Relevant: <a href=3D"https://idemix.wordpress.com/">https://=
idemix.wordpress.com/</a></p>
<p dir=3D"ltr">Anonymous Credentials allows an issuer to declare that you h=
ave certain rights. For example, upon paying the service provider could iss=
ue you the credentials for using their service up until a certain date. </p=
>
<p dir=3D"ltr">When challenged to prove a statement about what credentials =
you have, you can prove the fact that you've got the right credentials =
without revealing anything else. You don't even reveal you're the s=
ame person as the last time, if you prove the right to access a VPN multipl=
e times there's no data in it that links the different sessions togethe=
r. </p>
<p dir=3D"ltr">The main difference is that issuance of Anonymous Credential=
s aren't "atomic" with the payment transactions, which can op=
en up the risk for certain types of dishonest behavior by the seller. You c=
ould however use a proof in court of having paid for the credentials but no=
t getting them issued to you (maybe throw in usage of Factom to log issuanc=
e of credentials?). With this construction of using both these methods, you=
add stronger privacy for the usage of the services while simultaneously ke=
eping a degree of accountability for the payment. </p>
<p dir=3D"ltr">The Zerocoin developers also got a paper on a blockchain ver=
sion, "Distributed Anonymous Credentials". </p>
--bcaec53f3447646bc90511315db9--
|
