From: Mark Friedenbach <mark@monetize•io>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees
Date: Tue, 17 Jun 2014 15:28:36 -0700 [thread overview]
Message-ID: <53A0C114.8050904@monetize.io> (raw)
In-Reply-To: <d46aec$hdccva@ironport9.mayo.edu>
Not with current script, but there are mechanisms by which you can do a
digital signature where signing two pieces of information reveals the
ECDSA k parameter, thereby allowing anyone to recover the private key
and steal the coins.
Practically speaking, these are not very safe systems to use. For
example, imagine accidentally loading up the same wallet on two machines
or the wallet software crashing after signing and sending the
transaction, and the user recreates & sends on recovery.
It also invalidates reasonably legitimate use cases for repeating
addresses (in the absence of other solutions), and its not really
possible to prevent people from sending multiple coins to the same
address (which could then be stolen).
On 06/17/2014 01:40 PM, Goss, Brian C., M.D. wrote:
> Can two signed transactions using the same output as an input (ie, a
> double spend) be used to trigger a third transaction?
>
> It would be nice if I could sign a tx that would pay m bitcoins to an
> arbitrary address if and only if someone could present proof that I
> signed more than 1 transaction using the same output. Thus, a
> merchant could trust that I would not attempt a double spend for a
> purchase of n < m bitcoins.
>
> Can this type of transaction be expressed in Bitcoin's scripting
> language?
>
> Chaum had a similar feature in Digicash way back when...a double
> spend would let the second merchant compute the identity of the
> double spender and serve as proof of double spending. It didn't
> automate punishment though!
>
> My apologies if this has been discussed previously.
>
next prev parent reply other threads:[~2014-06-17 22:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
2014-06-17 20:40 ` Goss, Brian C., M.D.
2014-06-17 22:28 ` Mark Friedenbach [this message]
2014-06-16 16:30 [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Lawrence Nahum
2014-06-16 16:45 ` Mike Hearn
2014-06-16 16:56 ` Lawrence Nahum
2014-06-16 17:01 ` Mike Hearn
2014-06-16 17:16 ` Lawrence Nahum
2014-06-16 18:02 ` Alex Kotenko
2014-06-16 18:09 ` Mike Hearn
2014-06-16 20:29 ` Daniel Rice
2014-06-16 20:32 ` Mike Hearn
2014-06-16 20:37 ` Daniel Rice
2014-06-16 20:50 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
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=53A0C114.8050904@monetize.io \
--to=mark@monetize$(echo .)io \
--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