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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1SNQxT-0002Ik-I2
for bitcoin-development@lists.sourceforge.net;
Thu, 26 Apr 2012 15:50:15 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.113 as permitted sender)
client-ip=62.13.148.113; envelope-from=pete@petertodd.org;
helo=outmail148113.authsmtp.com;
Received: from outmail148113.authsmtp.com ([62.13.148.113])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1SNQxN-0004Tz-Qi for bitcoin-development@lists.sourceforge.net;
Thu, 26 Apr 2012 15:50:15 +0000
Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33])
by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
q3QFo3ik095100 for <bitcoin-development@lists.sourceforge.net>;
Thu, 26 Apr 2012 16:50:03 +0100 (BST)
Received: from savin.lan (206-248-185-238.dsl.teksavvy.com [206.248.185.238])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id q3QFnwaZ046537
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Thu, 26 Apr 2012 16:50:00 +0100 (BST)
Date: Thu, 26 Apr 2012 11:49:28 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20120426154928.GA13737@savin.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Server-Quench: 7bc13093-8fb7-11e1-ab46-001185d377ca
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQN1
IQgLXVBSFQd4ABoL Ax4UUhg8dQVAZnx0 bVhjVnVFXkdyakN1
RVFVWywFBBE+LzF1 UERecgBTPgtJeBcL bQIsVXANaGYabiwy
QEpqZj1oeDxVdHoQ GllUdAJPTR1UQTU1 USwYAC4zEEFNRik+ KQAnNl8RBy6Q
X-Authentic-SMTP: 61633532353630.1000:706
X-AuthFastPath: 0 (Was 255)
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1SNQxN-0004Tz-Qi
Subject: [Bitcoin-development] Trusted identities
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: Thu, 26 Apr 2012 15:50:15 -0000
--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
It recently occured to me that we can use the public nature of the block
chain to create trusted identities, for a specific form of trust.
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 other
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 way
to do this would of course be to transfer coins to a null address,
provably incurring a cost to her.
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 the
transaction fees for miners, which will be very important for the
network in the future.
Now Bob can easily examine the block chain, and upon verifying Alice's
trust purchase, can decide to accept a zero-confirmation transaction at
face value. If Alice breaks that promise, he simply publishes her signed
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.
In effect, we now have a distributed green address system.
Now Alice could try to mount a double-spend attack on a whole bunch of
people at once, hoping to have them all accept the transaction. However
as it is the "just trust them" model works pretty well already.
A good usecase for this idea, beyond the obvious fast payments
application, is a distributed anonymizer. Alice can now publish her
request to anonymize coins, and other trusted identities can make their
bids. If Alice accepts a bid from Bob, she will want Bob to send her the
anonymized coins *prior* to her transaction going through, thus breaking
the temporal connection between the transactions. Now Alice can give Bob
the signed payment transaction, and Bob can submit his payment
transaction to the network first, knowing that Alice isn't going to try
to rip him off. Bob can also have a trusted identity which signed the
contract for the anonymizer transaction, and similarly if he rips Alice
off, she can publish it for the world to see.
A more subtle effect, is this makes sybil attacks more difficult. To
pretend to be a thousand identities is going to now require 1,000 * n
coins, and attempting to pull this attack off inherently strengthens the
bitcoin network. Obviously we can apply this principle to other things
like tor nodes as well.
--=20
http://petertodd.org 'peter'[:-1]@petertodd.org
--AqsLC8rIMeq19msA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJPmW6EAAoJEH+rEUJn5PoEZfEH/ixptlMX9MzP71bCHMkj7YN1
y6GEkc1vNhyHu01NX77vzSqR4trbVnWJeJ5hH8EB5tgYRwmI17XoQW6Iz8yEXXgO
JqUKCTBBexGE+F5RfBkizJ9ap5wXwVrAOIMy/KurSdST+PWMXIPQFaGark01uKcG
M4VXg3U9fc/0Zz1QyKpRTI5O7ZSBqPzEh/Xf4TujR39nUtaI5mkT/bmA3+Te7oRT
34QO7ryF7U001Xz2VJCfm9AE8mPPZjMavLTs/XvPSqTdliVCZpjGGHzcJ2BPrni5
LEPBsBBxNsuwFGjnRobQwrkPtmYGFntseMLzCJ3iGXWYwedssBg2LLOx9QaXG04=
=PftQ
-----END PGP SIGNATURE-----
--AqsLC8rIMeq19msA--
|
