From: Timo Hanke <timo.hanke@web•de>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Date: Sun, 28 Apr 2013 20:03:04 +0200 [thread overview]
Message-ID: <20130428180304.GA30115@crunch> (raw)
In-Reply-To: <CABsx9T3egz=7YNOrgx7WsfSthLfN2gfE60YfPEv8096vyErBqg@mail.gmail.com>
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.
next prev parent reply other threads:[~2013-04-28 18:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
2013-04-25 9:58 ` Timo Hanke
2013-04-25 10:05 ` Mike Hearn
2013-04-25 10:28 ` Timo Hanke
2013-04-25 10:45 ` Mike Hearn
2013-04-25 10:52 ` Mike Hearn
2013-04-25 11:55 ` Timo Hanke
[not found] ` <FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>
2013-04-25 14:31 ` Mike Hearn
2013-04-25 19:12 ` Jeremy Spilman
2013-04-26 1:07 ` Gavin Andresen
2013-04-28 18:03 ` Timo Hanke [this message]
2013-04-29 18:40 ` Jeremy Spilman
2013-04-30 9:17 ` Mike Hearn
2013-04-30 11:32 ` Jouke Hofman
2013-04-30 13:14 ` Gavin Andresen
2013-04-30 17:17 ` Jeremy Spilman
2013-05-06 21:29 ` Peter Todd
2013-04-24 23:01 Jeremy Spilman
2013-04-24 23:07 ` Alan Reiner
2013-04-25 9:08 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130428180304.GA30115@crunch \
--to=timo.hanke@web$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox