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 1Wx0Bf-0002Yl-CW for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 20:40:59 +0000 X-ACL-Warn: Received: from mail10.mayo.edu ([129.176.114.198]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Wx0Bd-0003fD-Ka for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 20:40:59 +0000 Received: from unknown (HELO mail9.mayo.edu) ([10.146.65.138]) by ironport10-dlp.mayo.edu with ESMTP; 17 Jun 2014 15:38:02 -0500 Message-Id: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEALimoFMKgNEM/2dsb2JhbABRCYNfvFKHPQGBJXWEAwEBAQQBAjcCARwVGwIBCA0EAwECAS4oJwgCBAoJiEcIxHCFXo4gEgoBARw1BQaCf4E+BIVekgCEKIVgjjOBQmwBAYEJ Received: from unknown (HELO msgoms04.mayo.edu) ([10.128.209.12]) by ironport9.mayo.edu with ESMTP; 17 Jun 2014 15:37:10 -0500 Date: Tue, 17 Jun 2014 20:40:50 +0000 From: "Goss, Brian C., M.D." In-reply-to: To: "" MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Thread-index: AQHPimxsU5IXCA0G/kCUv7O6i9Klhg== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-CFilter-Loop: Reflected X-Spam-Score: -1.0 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [129.176.114.198 listed in list.dnswl.org] -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 MSGID_FROM_MTA_HEADER Message-Id was added by a relay X-Headers-End: 1Wx0Bd-0003fD-Ka 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 20:40:59 -0000 Can two signed transactions using the same output as an input (ie, a double= spend) be used to trigger a third transaction?=20 It would be nice if I could sign a tx that would pay m bitcoins to an arbit= rary 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.=20 Can this type of transaction be expressed in Bitcoin's scripting language?= =20 Chaum had a similar feature in Digicash way back when...a double spend woul= d let the second merchant compute the identity of the double spender and se= rve as proof of double spending. It didn't automate punishment though! My apologies if this has been discussed previously.=20 ----------------------------- >=20 > Message: 2 > Date: Mon, 16 Jun 2014 16:50:41 -0400 > From: Peter Todd > Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized > instant confirmation guarantees > To: Daniel Rice > Cc: Bitcoin Dev , Lawrence > Nahum > Message-ID: <20140616205041.GA21784@savin> > Content-Type: text/plain; charset=3D"us-ascii" >=20 >> On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote: >> True, that would work, but still how are you going to bootstrap the trus= t? >> TREZOR is well known, but in a future where there could be 100 different >> companies trying to release a similar product to TREZOR it seems like on= e >> company could corner the market by being the only one that is an accepte= d >> instant provider at most vendors. It seems to encourage monopoly unless >> there is a standard way to bootstrap trust in your signature. >=20 > You can always use fidelity bonds, or as I called it at the time(1), > "Trusted identities": >=20 > Lets suppose Alice has some bitcoins held at bitcoin address A. She > wants to establish trust in the "identity" associated with the ECC > keypair associated with A, for instance for the purpose of having othe= r > users trust her not to attempt to double spend. Since the trust she > seeks is financial in nature, she can do this by valuing the identity > associated with A, by delibrately throwing away resources. A simple wa= y > to do this would of course be to transfer coins to a null address, > provably incurring a cost to her. >=20 > A more socially responsible way would be for her to create a series of > transactions that happen to have large, and equal, transaction fees. > Bitcoin makes the assumption that no one entity controls more than 50% > of the network, so if she makes n of these transactions consecutively, > each spending m BTC to transaction fees, there is a high probability > that she has given up at least n/2 * m BTC of value. This of course is > all public knowledge, recorded in the block chain. It also increases t= he > transaction fees for miners, which will be very important for the > network in the future. >=20 > Now Bob can easily examine the block chain, and upon verifying Alice's > trust purchase, can decide to accept a zero-confirmation transaction a= t > face value. If Alice breaks that promise, he simply publishes her sign= ed > transaction proving that Alice is a fraudster, and future Bob's will > distrust Alice's trusted identity, thus destroying the value needed to > create it. >=20 > In effect, we now have a distributed green address system. >=20 > Note that the second paragraph is seriously obsolete - better to either > use announce-commit sacrifices, or much preferably, simple destruction > of coins. (sacrifice to fees encourages mining centralization for > obvious reasons) >=20 > 1) "[Bitcoin-development] Trusted identities", Apr 26th 2012, Peter Todd, > http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net= /msg01005.html >=20 > Incidentally, my first post to this mailing list! >=20 > --=20 > 'peter'[:-1]@petertodd.org > 000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 685 bytes > Desc: Digital signature >=20 > ------------------------------ >=20 >=20 >=20 > End of Bitcoin-development Digest, Vol 37, Issue 27 > ***************************************************