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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kalle@rosenbaum.se>) id 1YWiMb-0007iP-4Q
for bitcoin-development@lists.sourceforge.net;
Sat, 14 Mar 2015 09:28:09 +0000
X-ACL-Warn:
Received: from mail-qc0-f180.google.com ([209.85.216.180])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YWiMZ-0003ef-9R
for bitcoin-development@lists.sourceforge.net;
Sat, 14 Mar 2015 09:28:09 +0000
Received: by qcyi15 with SMTP id i15so7738758qcy.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 14 Mar 2015 02:28:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=E044tmZFnVjtIOGG/K+5msYdQZzmbSnrzwH0ZddQYjc=;
b=g1Mq8IfXT3emlwh7C8oenRJsajJKNMqbrVukgRJ6ZdEVeqwd7QCcI0g3qDXBYlkbi5
0Nr9Mg8mUzI0SImYksrPm22omUI2cONjZBlcgXIrL3zEZXac7uDeEPmkOdQDQ/AzYgMG
p841U4tcVPhYPXZNu4flgqi8mabpo4D1tRPKSNwpX254aZiJIu7BFhAJDOnwR/KrzUdw
idgpjBmBgb+owve72X7YkraVu2Pi8HPsn14u+7QMXGxgxvG2H4Hi+xtxfeZExx5jQmio
rpNsFoqvk2PdtN+cYu2N8rJWc9MPP+eh3RRDiyWd1frdg3qb7NQFNdzAmkjMfYw2OxWi
sHPg==
X-Gm-Message-State: ALoCoQkqNriJ3J13vLkxxAdgKGPF/yu4bvjudwor0C9hsDFyKMh14QPZQktqJev/zpzACgAuypN8
MIME-Version: 1.0
X-Received: by 10.140.144.11 with SMTP id 11mr41179647qhq.54.1426325281798;
Sat, 14 Mar 2015 02:28:01 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Sat, 14 Mar 2015 02:28:01 -0700 (PDT)
In-Reply-To: <CANEZrP35_h_-2c=A-1+M8umSpAC70DJ7sYhPPo_62dm2QKHCEg@mail.gmail.com>
References: <CAPswA9zzVDxW8_WXg5833r2Z4pxZOppYtNLHMQ=Nw-H72cMz7w@mail.gmail.com>
<CANEZrP0V4wg4X1ASx9_+ONP749s9TD3PcemA_wyjYvgZDxh+WA@mail.gmail.com>
<CAPswA9yicPa=4peZdjGXhrY64WwABj9rkq3vF5Lv1cEqhEER5w@mail.gmail.com>
<CANEZrP0U6MF7ibvb8gTdPbeczBn5UiOFN_NnMnOAuwr4sNFUXw@mail.gmail.com>
<CAPswA9y5bDs1urRCmh8Oxeho4As8pBt2rRVP6fjhjJA0cZrvfA@mail.gmail.com>
<CANEZrP35_h_-2c=A-1+M8umSpAC70DJ7sYhPPo_62dm2QKHCEg@mail.gmail.com>
Date: Sat, 14 Mar 2015 10:28:01 +0100
Message-ID: <CAPswA9wPWGQDWv-O0aBQt7L+-k4UpcRB+Z61CACzSUHU=O+HgQ@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11376540c18fe405113c3b39
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1YWiMZ-0003ef-9R
Cc: Bitcoin Dev <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: Sat, 14 Mar 2015 09:28:09 -0000
--001a11376540c18fe405113c3b39
Content-Type: text/plain; charset=UTF-8
>
> Actually, the security of the PaymetRequest is pretty much out of your
>> control as soon as the PaymentRequest is created on the server. You have no
>> idea what the hotel does with it. Also if it's stored in the hotel server I
>> have to trust the hotel to keep it safe for me.
>>
>
> Well, yes. But if the hotel itself is hacked then the whole process is
> meaningless, no? The hacker could just make the hotel think the proof of
> payment is correct even though it was never made at all, for instance.
>
Maybe the hotel example is not perfect for this discussion. Let's instead
assume that the server holds yearly subscriptions to some expensive video
service. If that service stores PaymentRequests for all their subscribers,
and accept them as proof of payment, that would be similar to storing
username and (possibly hashed) passwords for all subscribers. If all the
PaymentRequests for all users are stolen, then they have to shut down all
accounts if they discover the theft. If they don't discover the theft the
"accounts" are out in the wild, for sale, for blackmail, etc.
Wouldn't it be better if the service don't accept the reusable
PaymentRequests as proof, and instead accept a proof generated on demand,
at the very moment it is needed, and that it is only usable once? From a
usability perspective there is no difference; The users simply need access
the service and authorize the proof being sent to the server.
>
>
>> Another thing is that you assume BIP0070 is used for payments, which
>> isn't necessarily is the case.
>>
>
> It's just a convenient place to put things. There are lots of useful
> features that need BIP 70. I hope eventually all wallets will support it.
>
I also hope BIP0070 will take off. It would greatly improve the user
experience. But even then, all payments are not BIP0070. BIP0070 is
primarily for merchants who have the skills, time and money to use
certificates. I don't think a lottery at the local church would want to set
up a secure BIP0070 server, but they still might want to use bitcoin for
their lottery.
Regards,
Kalle
--001a11376540c18fe405113c3b39
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div><div><div>Actually, the security of the PaymetRequest is =
pretty much out of your control as soon as the PaymentRequest is created on=
the server. You have no idea what the hotel does with it. Also if it's=
stored in the hotel server I have to trust the hotel to keep it safe for m=
e.<br></div></div></div></div></blockquote><div><br></div></span><div>Well,=
yes. But if the hotel itself is hacked then the whole process is meaningle=
ss, no? The hacker could just make the hotel think the proof of payment is =
correct even though it was never made at all, for instance.</div></div></di=
v></div></blockquote><div><br></div><div>Maybe the hotel example is not per=
fect for this discussion. Let's instead assume that the server holds ye=
arly subscriptions to some expensive video service. If that service stores =
PaymentRequests for all their subscribers, and accept them as proof of paym=
ent, that would be similar to storing username and (possibly hashed) passwo=
rds for all subscribers. If all the PaymentRequests for all users are stole=
n, then they have to shut down all accounts if they discover the theft. If =
they don't discover the theft the "accounts" are out in the w=
ild, for sale, for blackmail, etc.<br><br></div><div>Wouldn't it be bet=
ter if the service don't accept the reusable PaymentRequests as proof, =
and instead accept a proof generated on demand, at the very moment it is ne=
eded, and that it is only usable once? From a usability perspective there i=
s no difference; The users simply need access the service and authorize the=
proof being sent to the server.<br></div><div>=C2=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D""><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><div><div></div><div>Another thing is that you=
assume BIP0070 is used for payments, which isn't necessarily is the ca=
se.<br></div></div></div></div></blockquote><div><br></div></span><div>It&#=
39;s just a convenient place to put things. There are lots of useful featur=
es that need BIP 70. I hope eventually all wallets will support it.</div></=
div></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">I also hope BIP0070=
will take off. It would greatly improve the user experience. But even then=
, all payments are not BIP0070. BIP0070 is primarily for merchants who have=
the skills, time and money to use certificates. I don't think a lotter=
y at the local church would want to set up a secure BIP0070 server, but the=
y still might want to use bitcoin for their lottery. <br><br></div><div cla=
ss=3D"gmail_extra">Regards,<br></div><div class=3D"gmail_extra">Kalle<br></=
div></div>
--001a11376540c18fe405113c3b39--
|
