From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UWVwK-000593-A9 for bitcoin-development@lists.sourceforge.net; Sun, 28 Apr 2013 18:03:08 +0000 Received: from mout.web.de ([212.227.15.3]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UWVwJ-0000DL-7I for bitcoin-development@lists.sourceforge.net; Sun, 28 Apr 2013 18:03:08 +0000 Received: from crunch ([217.50.173.229]) by smtp.web.de (mrweb101) with ESMTPA (Nemesis) id 0LrJse-1Uc3L70TEK-013du6; Sun, 28 Apr 2013 20:03:01 +0200 Date: Sun, 28 Apr 2013 20:03:04 +0200 From: Timo Hanke To: Gavin Andresen Message-ID: <20130428180304.GA30115@crunch> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V02:K0:2cEgKHi5/QcGU9I5g8XVUcRWhQ8ZRUWie6zRMDUl69W KyK/48hoaUntZYUrRHCwjHZwvNfYKhTt6S1GaZOG7zK2y3SLYk 1ZLGoBodY7nwqpgLYh3wb4s7UOGAv4vbVPMNh4xg461S7LvjQO 0UEJq7iDiqprYJKrOy5cFrwNDnzPSfrd2npxfNbyFbN9JO8siP UWgELFUy6hqnLS6nmAsvQ== X-Spam-Score: -2.4 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.15.3 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (timo.hanke[at]web.de) -2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UWVwJ-0000DL-7I Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Cold Signing Payment Requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: timo.hanke@web.de List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 18:03:08 -0000 On Thu, Apr 25, 2013 at 09:07:07PM -0400, Gavin Andresen wrote: > On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman wrote: > > > Right now I'm leaning towards writing a prototype using a single cert with > > a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey > > and InvoiceID in the Payment Request. Gavin, would the best way to work on > > this be to just fork your code on Github? > > > > As usual, our bottleneck is code review / testing, so it would be nice if > you spent some time reviewing code and helping test v0.9 so we can actually > ship a v1 sometime in the next several months before you start working on a > v2. How does the current protocol protect the refund address? Protecting the payee against a compromised webserver may be out of scope for now, due to the lack of a suitable PKI, as Mike Hearn explained. But signing the refund address is a more immediate issue. There is no obvious key that the payer can use to sign the refund address. However, this can be solved right now with marginal changes to the protocol, like this: - Payee creates his PaymentDetails message with an explicit pubkey in output.script, not an address. - If payment_url is not specified then payer pays as before (he cannot sign his refund address) - If payment_url is specified then payer hashes his Payment message (with transactions zeroed out) and pays to h*pubkey, where h is the computed hash; then submits his Payment message. - Upon receiving the Payment message, payee computes the same hash and can pick his funds from h*pubkey. As long as it is trivial to reconstruct the Payment message this is completely safe. But probably this isn't the case in general. So the drawback is that the payer has to backup the Payment message before submitting it or before broadcasting the transaction, in order to keep a proof. If the payer trusted the payee then it would suffice to wait for an ACK before broadcasting. Because of the backup issue, refund address signing should probably be an option that the payer can choose after reading a backup warning.