From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Fri, 13 Mar 2015 14:31:29 -0700 X-Google-Sender-Auth: F8FBNlSQi56cgRw8_WfHDNORDkA Message-ID: From: Mike Hearn To: Kalle Rosenbaum 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 Subject: Re: [Bitcoin-development] Proof of Payment X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi Kalle,

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>
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>

Do you agree with this = analysis?
--20cf303bf5623d88ea05113239e1--