From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wx1rz-0007Vo-JO for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 22:28:47 +0000 Received: from mail-pb0-f42.google.com ([209.85.160.42]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wx1rx-0007tp-Sq for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 22:28:47 +0000 Received: by mail-pb0-f42.google.com with SMTP id ma3so15897pbc.1 for ; Tue, 17 Jun 2014 15:28:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=afMY9C5qGBbingqVMdD0cxOjiq4K8dnJJ+8MGUh4QE0=; b=J+3NKH7DbjS4KniHbWI2rI0YA9LZ9n+A9Pr8ew1PteY4XGa/dfExbwTBChEx1G2CkO dAXNrSahXoF54uG6PGGxzONeV6ASRCJXiAv5064CBkbDU1/Phzf3IMAA7K67wLpYtazF +w+Bqn8PQompicc7YN4a5cCJHVpJN8tpS/Fok/lLSEzlqVdGiIXdudIMmVFbFicPlNps 6nAb7N9KsIRdS6BeaQFk2JdG9yoBCVRanJo7yd8osjT4KMe+SzZruVSdnkcmC5TrPWwv uHJIP25rLmr+ziaguCww2t4EPznsoYBCZwHhlrIVFCZXii168uR/UphMW1M6aR6v5bw4 05Fg== X-Gm-Message-State: ALoCoQk1YWI7bEFwXv4wGX8AW7LENBUqniyJtvoXJyfLU0n8Cg5CfOaubVNalufYMmZ8xWa+qmBm X-Received: by 10.68.254.70 with SMTP id ag6mr35701146pbd.33.1403044119934; Tue, 17 Jun 2014 15:28:39 -0700 (PDT) Received: from [192.168.127.194] (50-0-36-179.dsl.dynamic.sonic.net. [50.0.36.179]) by mx.google.com with ESMTPSA id qj3sm25657168pbc.91.2014.06.17.15.28.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 15:28:39 -0700 (PDT) Message-ID: <53A0C114.8050904@monetize.io> Date: Tue, 17 Jun 2014 15:28:36 -0700 From: Mark Friedenbach 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: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Wx1rx-0007tp-Sq Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:28:47 -0000 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. >