Message-Id: <d46aec$hdccva@ironport9.mayo.edu>
Date: Tue, 17 Jun 2014 20:40:50 +0000
From: "Goss, Brian C., M.D." <Goss.Brian@mayo.edu>
In-reply-to: <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
To: "<bitcoin-development@lists.sourceforge.net>"
	<bitcoin-development@lists.sourceforge.net>
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==
References: <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized instant
 confirmation guarantees
Precedence: list

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 <pete@petertodd.org>
> Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized
>    instant confirmation guarantees
> To: Daniel Rice <drice@greenmangosystems.com>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,    Lawrence
>    Nahum <lawrence@greenaddress.it>
> 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
> ***************************************************