Date: Sun, 28 Apr 2013 20:03:04 +0200
From: Timo Hanke <timo.hanke@web.de>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20130428180304.GA30115@crunch>
References: <CABsx9T3egz=7YNOrgx7WsfSthLfN2gfE60YfPEv8096vyErBqg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T3egz=7YNOrgx7WsfSthLfN2gfE60YfPEv8096vyErBqg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Precedence: list
Reply-To: timo.hanke@web.de

On Thu, Apr 25, 2013 at 09:07:07PM -0400, Gavin Andresen wrote:
> On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman <jeremy.spilman@gmail.com>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.