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
|
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 1YWXQN-0001kb-RX
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 21:47:19 +0000
X-ACL-Warn:
Received: from mail-qg0-f43.google.com ([209.85.192.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YWXQM-0001Hv-Id
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 21:47:19 +0000
Received: by qgfh3 with SMTP id h3so29347463qgf.2
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Mar 2015 14:47:13 -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=FGxd/BAvLpqrFZFlocgIsH0LIAHHiE9hJ2MeZRSuHp4=;
b=fyDK1sBTQoNY6HcufcAQpi8V8ZnNKUrLH6tbhhqD4uC6ee7GsnjWhNHvaU6hGB2uy2
3cREm++OsEww9rZdCwe9L5RYTxZTFrfFpwyKaVTSzzkMq7MfFWkYvY2BL1GHklT1V6l8
0xvpI8jjWAVlkMxNNSapKQ91002vN7y/9Et4nG6aRBaKCVgmIqdcOHrN12KCxoEOwUXD
exJHVrQnom2DmaaeTjFN3yO4lDkMijZHHRkWlr0tktWVKPGZOHWfAdM+nkU0mvSjZS1W
acpsHETTGQYPsjTmWYh2CgAQITsbLkRQw2xt7EXKBu4wSY+LarOgOUmMkxt/D5SNy0BZ
b5hQ==
X-Gm-Message-State: ALoCoQkW66ZfEc4sapcDxWVWCB8+gOlVJe9nwDGPy0auhiZx96qmfzB1IQGPhbQ+agTGrXrDJ9bA
MIME-Version: 1.0
X-Received: by 10.55.23.84 with SMTP id i81mr35881483qkh.51.1426283232945;
Fri, 13 Mar 2015 14:47:12 -0700 (PDT)
Received: by 10.96.145.9 with HTTP; Fri, 13 Mar 2015 14:47:12 -0700 (PDT)
In-Reply-To: <CANEZrP0V4wg4X1ASx9_+ONP749s9TD3PcemA_wyjYvgZDxh+WA@mail.gmail.com>
References: <CAPswA9zzVDxW8_WXg5833r2Z4pxZOppYtNLHMQ=Nw-H72cMz7w@mail.gmail.com>
<CANEZrP0V4wg4X1ASx9_+ONP749s9TD3PcemA_wyjYvgZDxh+WA@mail.gmail.com>
Date: Fri, 13 Mar 2015 22:47:12 +0100
Message-ID: <CAPswA9yicPa=4peZdjGXhrY64WwABj9rkq3vF5Lv1cEqhEER5w@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a1146fe6272fee705113271c2
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: 1YWXQM-0001Hv-Id
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: Fri, 13 Mar 2015 21:47:19 -0000
--001a1146fe6272fee705113271c2
Content-Type: text/plain; charset=UTF-8
Hi
No I don't agree with the analysis.
Yes, the PaymentRequest can be stored with the same security as the private
keys are stored. The big difference is that the keys never leave the
wallet. As soon as that PaymentRequest leaves the wallet on its way to the
hotel server, it is up for grabs which makes it inappropriate for use as a
proof of payment other than for resolving disputes and other one-time stuff.
/Kalle
2015-03-13 22:31 GMT+01:00 Mike Hearn <mike@plan99.net>:
> Hi Kalle,
>
> I think you're thinking along the right lines, but I am skeptical that
> this protocol adds much. A saved payment request is meant to be unique per
> transaction e.g. because the destination address is unique for that payment
> (for privacy reasons). Where would you store the signed payment request?
> Probably in the wallet. You could just extract the metadata that's useful
> for UI rendering into a separate structure and then encrypt the original
> full payment request under the wallet key. At least this is how I imagine
> it would work.
>
> So then, if someone can steal a payment request they can probably steal
> the wallet signing keys too, and thus signing a challenge with the wallet
> keys doesn't add much. It means the wallet doesn't have to store the
> PaymentRequest encrypted. But AFAICT that's about all it does.
>
> Do you agree with this analysis?
>
--001a1146fe6272fee705113271c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi<br><br></div><div>No I don't agree with the an=
alysis.<br></div><div><br></div><div>Yes, the PaymentRequest can be stored =
with the same security as the private keys are stored. The big difference i=
s that the keys never leave the wallet. As soon as that PaymentRequest leav=
es the wallet on its way to the hotel server, it is up for grabs which make=
s it inappropriate for use as a proof of payment other than for resolving d=
isputes and other one-time stuff.<br><br></div><div>/Kalle<br></div><div><b=
r></div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>2015-03-13 22:31 GMT+01:00 Mike Hearn <span dir=3D"ltr"><<a href=3D"mai=
lto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span>:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Kalle,<div><br></div><div=
>I think you're thinking along the right lines, but I am skeptical that=
this protocol adds much. A saved payment request is meant to be unique per=
transaction e.g. because the destination address is unique for that paymen=
t (for privacy reasons). Where would you store the signed payment request? =
Probably in the wallet. You could just extract the metadata that's usef=
ul for UI rendering into a separate structure and then encrypt the original=
full payment request under the wallet key. At least this is how I imagine =
it would work.</div><div><br></div><div>So then, if someone can steal a pay=
ment request they can probably steal the wallet signing keys too, and thus =
signing a challenge with the wallet keys doesn't add much. It means the=
wallet doesn't have to store the PaymentRequest encrypted. But AFAICT =
that's about all it does.</div><div><br></div><div><div class=3D"gmail_=
extra">Do you agree with this analysis?</div></div></div>
</blockquote></div><br></div></div></div></div>
--001a1146fe6272fee705113271c2--
|
