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 ) 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 ; 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: References: Date: Fri, 13 Mar 2015 22:47:12 +0100 Message-ID: From: Kalle Rosenbaum To: Mike Hearn 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 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: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 : > 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
Hi

No I don't agree with the an= alysis.

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.

/Kalle

2015-03-13 22:31 GMT+01:00 Mike Hearn <mike@plan99.net>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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 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.

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.

Do you agree with this analysis?

--001a1146fe6272fee705113271c2--