Message-ID: <53A0C114.8050904@monetize.io>
Date: Tue, 17 Jun 2014 15:28:36 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
	<d46aec$hdccva@ironport9.mayo.edu>
In-Reply-To: <d46aec$hdccva@ironport9.mayo.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized instant
 confirmation guarantees
Precedence: list

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.
>