From: Jeremy Spilman <jeremy.spilman@gmail•com>
To: timo.hanke@web•de,
Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Date: Mon, 29 Apr 2013 11:40:29 -0700 [thread overview]
Message-ID: <CA+CODZEiWTrmFzrMi2Mi0qtH3dWO5UWx_j09iUwV2qm1O=3o0A@mail.gmail.com> (raw)
In-Reply-To: <20130428180304.GA30115@crunch>
[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]
It's neat to use the payment address as an implicit signature by hashing
something and multiplying it into the payee's pubKey.
One downside is that it complicates the merchant's wallet. In this case
the payment is going to a pseudo-random address which the merchant will
have to explicitly add to their wallet, complicating backups, etc.
The other challenge is how to handle an error when you POST to the
payment_url. In the original spec, the payer would only broadcast the
transaction themselves if there wasn't a payment_url. In the current
version it looks like the payer will broadcast the transaction(s) either
way. I only saw some of the discussions around this, but I think part of
the problem is what state do you put the payer's wallet into if you POST a
Payment and don't get a PaymentAck? If the payer always broadcasts the
transaction, then wallet state becomes obvious. With your proposal you
would not want the payer to broadcast the transaction without a PaymentAck,
since you need the merchant to acknowledge they know where to look for the
payment.
Backing up a step, I'm not sure what the threat model is for signing the
refund address? The same process that's signing the transaction is doing an
HTTPS POST with the refund address. If an attacker can defeat that, then
they can just redirect the payment in the first place. The only benefit I
can think of is the payer can prove what refund address they specified with
the payment.
Wouldn't it be easier to just get the merchant to sign the PaymentAck?
Technically they already are signing it, but a TLS stream probably isn't
the most convenient way to capture that.
[-- Attachment #2: Type: text/html, Size: 1887 bytes --]
next prev parent reply other threads:[~2013-04-29 18:40 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
2013-04-29 18:40 ` Jeremy Spilman [this message]
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='CA+CODZEiWTrmFzrMi2Mi0qtH3dWO5UWx_j09iUwV2qm1O=3o0A@mail.gmail.com' \
--to=jeremy.spilman@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=timo.hanke@web$(echo .)de \
/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