From: Jeremy Spilman <jeremy.spilman@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Date: Tue, 30 Apr 2013 10:17:23 -0700 [thread overview]
Message-ID: <CA+CODZHr3h21chGX5YxvuU7LQCneF51h1gKD3ezgfucDO5w30A@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0TTZC0EOO3ZLa3cTWhpYJaEVrQ1vO8ofaGbcDJRmfWYA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
> 1) The risk that the merchant's web server will be compromised and the
attacker will redirect refunds
> 2) The risk that the merchant will miss payments because they miss a POST
to the payment_url (maybe the customer's machine crashes during the HTTPS
handshake)
> If payments are a lot more common than refunds, then (2) will outweigh
(1).
I think that's oversimplifying. (1) is theft, (2) is payment processing.
Reliable payment processing with refund handling is not simple nor free,
but it should be secure. The cost of (2) depends primarily on the failure
rate, which we can only guess at this point, and secondarily on how much
manual intervention is required to recover.
(2) is perhaps more of a problem if wallets broadcast before POST. It's
trading one failure mode (funds sent but not claimed) for another (coins
marked as spent but not). Either way, you fix it by just retrying the POST.
But only with Transmit-After-ACK can the payer's wallet detect the failure
automatically, and even recover automatically (simply unlock the outputs,
or to be sure, spend them back to self).
Since merchants get to choose whether to have a POST url, they get to
decide if the cost of keeping their server up is worth it. I think
eventually there are enough benefits to Transmit-After-ACK that it will
become a supported use case.
Thanks Mike for explaining the threat.
[Aside] I was reading Peter's fidelitybond writeup for his idea on contract
value accounting, and he points to Stephan's post from last September on
payer-encoded metadata (
https://bitcointalk.org/index.php?topic=108423.msg1178438#msg1178438) which
Timo applies here. As a relative newcomer, this is what I am loving most
about Bitcoin.
[-- Attachment #2: Type: text/html, Size: 2752 bytes --]
next prev parent reply other threads:[~2013-04-30 17:17 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
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 [this message]
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+CODZHr3h21chGX5YxvuU7LQCneF51h1gKD3ezgfucDO5w30A@mail.gmail.com \
--to=jeremy.spilman@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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