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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YWXBC-0005pb-HQ
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 21:31:38 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.169 as permitted sender)
client-ip=209.85.223.169; envelope-from=mh.in.england@gmail.com;
helo=mail-ie0-f169.google.com;
Received: from mail-ie0-f169.google.com ([209.85.223.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YWXBB-0000po-FB
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 21:31:38 +0000
Received: by iecsl2 with SMTP id sl2so127068262iec.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Mar 2015 14:31:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.186.130 with SMTP id cs2mr5182883icb.74.1426282289913;
Fri, 13 Mar 2015 14:31:29 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.36.54.147 with HTTP; Fri, 13 Mar 2015 14:31:29 -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 14:31:29 -0700
X-Google-Sender-Auth: F8FBNlSQi56cgRw8_WfHDNORDkA
Message-ID: <CANEZrP0V4wg4X1ASx9_+ONP749s9TD3PcemA_wyjYvgZDxh+WA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
Content-Type: multipart/alternative; boundary=20cf303bf5623d88ea05113239e1
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1YWXBB-0000po-FB
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:31:38 -0000
--20cf303bf5623d88ea05113239e1
Content-Type: text/plain; charset=UTF-8
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?
--20cf303bf5623d88ea05113239e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Kalle,<div><br></div><div>I think you're thinking a=
long the right lines, but I am skeptical that this protocol adds much. A sa=
ved 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 co=
uld just extract the metadata that's useful for UI rendering into a sep=
arate structure and then encrypt the original full payment request under th=
e wallet key. At least this is how I imagine it would work.</div><div><br><=
/div><div>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 w=
allet keys doesn't add much. It means the wallet doesn't have to st=
ore 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>
--20cf303bf5623d88ea05113239e1--
|
