<div class="gmail_extra">These are interesting thoughts, karma for bitcoins essentially.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I would like CoinLab to publish a &#39;cost of subverting 1-n transactions with 90% probability&#39; metric soon, and I think it would help everyone to understand what that number is.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">When we started out, you probably needed to wait 5 blocks for $10 or $20 of bitcoin value transfer.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

Now, I&#39;d happily accept a $1k transaction with 1 confirmation. </div><div class="gmail_extra"><br></div><div class="gmail_extra">More difficulty shortens the safe time we can transact large volumes in, which is good for the network.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I&#39;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?</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Peter</div><div class="gmail_extra"> </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd <span dir="ltr">&lt;<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It recently occured to me that we can use the 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 &quot;identity&quot; associated with the ECC<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&#39;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&#39;s will<br>
distrust Alice&#39;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 &quot;just trust them&quot; model works pretty well already.<br>
<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&#39;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="HOEnZb"><font color="#888888"><br>
--<br>
<a href="http://petertodd.org" target="_blank">http://petertodd.org</a> &#39;peter&#39;[:-1]@<a href="http://petertodd.org" target="_blank">petertodd.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=<br>
=PftQ<br>
-----END PGP SIGNATURE-----<br>
<br>------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today&#39;s security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><table style="font-family:Times"><tbody><tr><td><img src="http://coinlab.com/images/coinlab-logo.png"></td><td valign="bottom"><div style="font-family:RobotoLight,&#39;Lucida Grande&#39;,Helmet,Freesans,sans-serif;font-size:16px;line-height:20px">

Peter J. Vessenes<br>CEO, CoinLab<br>M: 206.595.9839<br>Skype: vessenes<br><a href="https://plus.google.com/112885659993091300749" target="_blank">Google+</a></div></td></tr></tbody></table><br>
</div>