1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
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 <Goss.Brian@mayo.edu>) 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: <d46aec$hdccva@ironport9.mayo.edu>
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." <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==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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
> ***************************************************
|
