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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <peter@coinlab.com>) id 1SNSeg-0005Qa-Ln
for bitcoin-development@lists.sourceforge.net;
Thu, 26 Apr 2012 17:38:58 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.213.175 as permitted sender)
client-ip=209.85.213.175; envelope-from=peter@coinlab.com;
helo=mail-yx0-f175.google.com;
Received: from mail-yx0-f175.google.com ([209.85.213.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SNSea-0001H6-RT
for bitcoin-development@lists.sourceforge.net;
Thu, 26 Apr 2012 17:38:58 +0000
Received: by yenm3 with SMTP id m3so1366073yen.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 26 Apr 2012 10:38:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type:x-gm-message-state;
bh=P7LkvVUvMhudDYgWm5HSeAoaHKuogZMPLbrSFtL5JGs=;
b=JGEsxtpamT1XVX+JIlV5TY3EAfhPTmGHMnVkhVEKmpSlI4pQIxvOniZXJBsSfskN8d
d+xIoiMwd+FZeYrv++OcZiHiXX9ZvSB7ms7OH8Zj3ztyrBqX30zrsursHW34kD1CCWXd
O7vrNToT8NuMKJS6N7PGfTO0cWWlp2+z0rcJrsLPUtIqIxGoKOETFx3btJHZlukwo7sN
BkY2oZ61a4DQcZGLcB7CcMCZWJ4uhUPqpn9MYG1tQBnlw13wrT2W4Y9nqmwmBjdQuVzg
+KjhC799o6m84LQUe8dIcE6+1nT+ieNRrB7/7ejqUvGw2YpVRt/kRE5nUubwnH88BuEg
lgAw==
Received: by 10.60.31.67 with SMTP id y3mr9682192oeh.41.1335460332213; Thu, 26
Apr 2012 10:12:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.56.226 with HTTP; Thu, 26 Apr 2012 10:11:51 -0700 (PDT)
In-Reply-To: <20120426154928.GA13737@savin.lan>
References: <20120426154928.GA13737@savin.lan>
From: Peter Vessenes <peter@coinlab.com>
Date: Thu, 26 Apr 2012 10:11:51 -0700
Message-ID: <CAMGNxUs3eDaYHpg=ZqXQPC5+kQXZwhqUngH2t2OFaTa4x7vPcw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=e89a8f647b71b696bc04be9816fb
X-Gm-Message-State: ALoCoQkYe/7q+EWAVRefl59X+krWCkH+7S/4k85MYPFzQFnlbu/FRefkJBUP1yTCTfOe07u8ROkr
X-Spam-Score: -0.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
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1SNSea-0001H6-RT
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [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 17:38:58 -0000
--e89a8f647b71b696bc04be9816fb
Content-Type: text/plain; charset=ISO-8859-1
These are interesting thoughts, karma for bitcoins essentially.
I would like CoinLab to publish a 'cost of subverting 1-n transactions with
90% probability' metric soon, and I think it would help everyone to
understand what that number is.
When we started out, you probably needed to wait 5 blocks for $10 or $20 of
bitcoin value transfer.
Now, I'd happily accept a $1k transaction with 1 confirmation.
More difficulty shortens the safe time we can transact large volumes in,
which is good for the network.
I'm not sure of the current implementation of replacement transactions, can
anyone on the core team speak to this? Can I replace transactions, or is
that part of the spec unimplemented or deprecated right now?
Peter
On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd <pete@petertodd.org> wrote:
> 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.
>
> --
> http://petertodd.org 'peter'[:-1]@petertodd.org
>
> -----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-----
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
--e89a8f647b71b696bc04be9816fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_extra">These are interesting thoughts, karma for bitcoi=
ns essentially.</div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">I would like CoinLab to publish a 'cost of subverting 1-n tra=
nsactions with 90% probability' metric soon, and I think it would help =
everyone to understand what that number is.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">When we sta=
rted out, you probably needed to wait 5 blocks for $10 or $20 of bitcoin va=
lue transfer.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra">
Now, I'd happily accept a $1k transaction with 1 confirmation.=A0</div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">More diffic=
ulty shortens the safe time we can transact large volumes in, which is good=
for the network.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I'm not=
sure of the current implementation of replacement transactions, can anyone=
on the core team speak to this? Can I replace transactions, or is that par=
t of the spec unimplemented or deprecated right now?</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Peter</div>=
<div class=3D"gmail_extra">=A0</div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd <span dir=3D=
"ltr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@pete=
rtodd.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It recently occured to me that we can use th=
e public nature of the block<br>
chain to create trusted identities, for a specific form of trust.<br>
<br>
Lets suppose Alice has some bitcoins held at bitcoin address A. She<br>
wants to establish trust in the "identity" associated with the EC=
C<br>
keypair associated with A, for instance for the purpose of having other<br>
users trust her not to attempt to double spend. Since the trust she<br>
seeks is financial in nature, she can do this by valuing the identity<br>
associated with A, by delibrately throwing away resources. A simple way<br>
to do this would of course be to transfer coins to a null address,<br>
provably incurring a cost to her.<br>
<br>
A more socially responsible way would be for her to create a series of<br>
transactions that happen to have large, and equal, transaction fees.<br>
Bitcoin makes the assumption that no one entity controls more than 50%<br>
of the network, so if she makes n of these transactions consecutively,<br>
each spending m BTC to transaction fees, there is a high probability<br>
that she has given up at least n/2 * m BTC of value. This of course is<br>
all public knowledge, recorded in the block chain. It also increases the<br=
>
transaction fees for miners, which will be very important for the<br>
network in the future.<br>
<br>
Now Bob can easily examine the block chain, and upon verifying Alice's<=
br>
trust purchase, can decide to accept a zero-confirmation transaction at<br>
face value. If Alice breaks that promise, he simply publishes her signed<br=
>
transaction proving that Alice is a fraudster, and future Bob's will<br=
>
distrust Alice's trusted identity, thus destroying the value needed to<=
br>
create it.<br>
<br>
In effect, we now have a distributed green address system.<br>
<br>
Now Alice could try to mount a double-spend attack on a whole bunch of<br>
people at once, hoping to have them all accept the transaction. However<br>
as it is the "just trust them" model works pretty well already.<b=
r>
<br>
<br>
A good usecase for this idea, beyond the obvious fast payments<br>
application, is a distributed anonymizer. Alice can now publish her<br>
request to anonymize coins, and other trusted identities can make their<br>
bids. If Alice accepts a bid from Bob, she will want Bob to send her the<br=
>
anonymized coins *prior* to her transaction going through, thus breaking<br=
>
the temporal connection between the transactions. Now Alice can give Bob<br=
>
the signed payment transaction, and Bob can submit his payment<br>
transaction to the network first, knowing that Alice isn't going to try=
<br>
to rip him off. Bob can also have a trusted identity which signed the<br>
contract for the anonymizer transaction, and similarly if he rips Alice<br>
off, she can publish it for the world to see.<br>
<br>
A more subtle effect, is this makes sybil attacks more difficult. To<br>
pretend to be a thousand identities is going to now require 1,000 * n<br>
coins, and attempting to pull this attack off inherently strengthens the<br=
>
bitcoin network. Obviously we can apply this principle to other things<br>
like tor nodes as well.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"http://petertodd.org" target=3D"_blank">http://petertodd.org</a>=
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pe=
tertodd.org</a><br>
</font></span><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iQEcBAEBAgAGBQJPmW6EAAoJEH+rEUJn5PoEZfEH/ixptlMX9MzP71bCHMkj7YN1<br>
y6GEkc1vNhyHu01NX77vzSqR4trbVnWJeJ5hH8EB5tgYRwmI17XoQW6Iz8yEXXgO<br>
JqUKCTBBexGE+F5RfBkizJ9ap5wXwVrAOIMy/KurSdST+PWMXIPQFaGark01uKcG<br>
M4VXg3U9fc/0Zz1QyKpRTI5O7ZSBqPzEh/Xf4TujR39nUtaI5mkT/bmA3+Te7oRT<br>
34QO7ryF7U001Xz2VJCfm9AE8mPPZjMavLTs/XvPSqTdliVCZpjGGHzcJ2BPrni5<br>
LEPBsBBxNsuwFGjnRobQwrkPtmYGFntseMLzCJ3iGXWYwedssBg2LLOx9QaXG04=3D<br>
=3DPftQ<br>
-----END PGP SIGNATURE-----<br>
<br>-----------------------------------------------------------------------=
-------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><table s=
tyle=3D"font-family:Times"><tbody><tr><td><img src=3D"http://coinlab.com/im=
ages/coinlab-logo.png"></td><td valign=3D"bottom"><div style=3D"font-family=
:RobotoLight,'Lucida Grande',Helmet,Freesans,sans-serif;font-size:1=
6px;line-height:20px">
Peter J. Vessenes<br>CEO, CoinLab<br>M: 206.595.9839<br>Skype: vessenes<br>=
<a href=3D"https://plus.google.com/112885659993091300749" target=3D"_blank"=
>Google+</a></div></td></tr></tbody></table><br>
</div>
--e89a8f647b71b696bc04be9816fb--
|
