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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proof of Payment
Precedence: list

--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&#39;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&#39;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&#39;t add much. It means the wallet doesn&#39;t have to st=
ore the PaymentRequest encrypted. But AFAICT that&#39;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--