Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SNSyu-0004RW-8v for bitcoin-development@lists.sourceforge.net; Thu, 26 Apr 2012 17:59:52 +0000 X-ACL-Warn: Received: from nm34-vm1.bullet.mail.ne1.yahoo.com ([98.138.229.81]) by sog-mx-3.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1SNSyt-0000KU-2H for bitcoin-development@lists.sourceforge.net; Thu, 26 Apr 2012 17:59:52 +0000 Received: from [98.138.90.57] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 26 Apr 2012 17:59:45 -0000 Received: from [98.138.87.8] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 26 Apr 2012 17:59:45 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 26 Apr 2012 17:59:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 269193.61106.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 89426 invoked by uid 60001); 26 Apr 2012 17:59:45 -0000 X-YMail-OSG: t20wNSQVM1mK5k6nmJwJ8ok7Y5QCK2G0dV53vDDvAohHO6E pzh6r4Do8PJFr0PQdjZGu.gOB._Z_q7XGa0RvovvpfteuFdjCRBak_7MlxVi opFgssKHZTQw4nFMY0CPwT7t2j93i2Yyif8axVt5cN8Lz3oaPXhfLXRWEjma IuA7TIMt30Sea6XCO_8Fgsjgppc3q4IniPAU5wAqogqlIwl5C_xxbEGzwI5D mlhXd0Fox00AO5Imxn6FzwQ3a_SUa_WDDGhS8dWgAd_O6G9bGNr1SEgjCkFQ yGvAEC327_2aH2.hAWD4p4eGDP9SFtJ_gKWp3uQn6YcCGWGrE3kr._MYYgBZ ddS4pYnMAirdyWcWFYnzWLyKtsBL7nTGOBDY5zge_8zOr_kDTYP8bJxx05T7 bZ2Y2OOFbcG50KZMC4VL3TUwdKkqBcNDK6JBfRN26ByhY52mh5fech1o8ndz _T9cpI9M3YVIvvN0FxmH5rS6DsGifCDKpxvm1zmsMq8cHCt794NdN0kHnvKQ wni37tBZCqxaZIv57pygOWPZIjWCGlV3XnKQRhCHM0GfE1jXDxkRr8Lcbpw- - Received: from [92.20.154.114] by web121004.mail.ne1.yahoo.com via HTTP; Thu, 26 Apr 2012 10:59:45 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <20120426154928.GA13737@savin.lan> Message-ID: <1335463185.72832.YahooMailNeo@web121004.mail.ne1.yahoo.com> Date: Thu, 26 Apr 2012 10:59:45 -0700 (PDT) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.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 [98.138.229.81 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1SNSyt-0000KU-2H Subject: Re: [Bitcoin-development] Trusted identities X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:59:52 -0000 look at the first line of the if statement=0A=0A=0A=A0=A0=A0=A0// Check for= conflicts with in-memory transactions=0A=A0=A0=A0=A0CTransaction* ptxOld = =3D NULL;=0A=A0=A0=A0=A0for (unsigned int i =3D 0; i < tx.vin.size(); i++)= =0A=A0=A0=A0=A0{=0A=A0=A0=A0=A0=A0=A0=A0=A0COutPoint outpoint =3D tx.vin[i]= .prevout;=0A=A0=A0=A0=A0=A0=A0=A0=A0if (mapNextTx.count(outpoint))=0A=A0=A0= =A0=A0=A0=A0=A0=A0{=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0// Disable replac= ement feature for now=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return false;= =0A=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0// Allow replacing with a newer v= ersion of the same transaction=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (i = !=3D 0)=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return false;=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ptxOld =3D mapNextTx[outpoint].ptx;=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (ptxOld->IsFinal())=0A=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return false;=0A=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0if (!tx.IsNewerThan(*ptxOld))=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0return false;=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0fo= r (unsigned int i =3D 0; i < tx.vin.size(); i++)=0A=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0{=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0COutPoint o= utpoint =3D tx.vin[i].prevout;=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx !=3D ptxOld= )=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return fals= e;=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0break;=0A=A0=A0=A0=A0=A0=A0=A0=A0}=0A=A0=A0=A0=A0}=0A=0A=0A__________= ______________________=0AFrom: Peter Vessenes =0ATo: Pet= er Todd =0ACc: bitcoin-development@lists.sourceforge.n= et =0ASent: Thursday, April 26, 2012 6:11 PM=0ASubject: Re: [Bitcoin-develo= pment] Trusted identities=0A=0A=0AThese are interesting thoughts, karma for= bitcoins essentially.=0A=0AI would like CoinLab to publish a 'cost of subv= erting 1-n transactions with 90% probability' metric soon, and I think it w= ould help everyone to understand what that number is.=0A=0AWhen we started = out, you probably needed to wait 5 blocks for $10 or $20 of bitcoin value t= ransfer.=0A=0ANow, I'd happily accept a $1k transaction with 1 confirmation= .=A0=0A=0AMore difficulty shortens the safe time we can transact large volu= mes in, which is good for the network.=0A=0AI'm not sure of the current imp= lementation of replacement transactions, can anyone on the core team speak = to this? Can I replace transactions, or is that part of the spec unimplemen= ted or deprecated right now?=0A=0APeter=0A=0A=0A=0AOn Thu, Apr 26, 2012 at = 8:49 AM, Peter Todd wrote:=0A=0AIt recently occured to= me that we can use the public nature of the block=0A>chain to create trust= ed identities, for a specific form of trust.=0A>=0A>Lets suppose Alice has = some bitcoins held at bitcoin address A. She=0A>wants to establish trust in= the "identity" associated with the ECC=0A>keypair associated with A, for i= nstance for the purpose of having other=0A>users trust her not to attempt t= o double spend. Since the trust she=0A>seeks is financial in nature, she ca= n do this by valuing the identity=0A>associated with A, by delibrately thro= wing away resources. A simple way=0A>to do this would of course be to trans= fer coins to a null address,=0A>provably incurring a cost to her.=0A>=0A>A = more socially responsible way would be for her to create a series of=0A>tra= nsactions that happen to have large, and equal, transaction fees.=0A>Bitcoi= n makes the assumption that no one entity controls more than 50%=0A>of the = network, so if she makes n of these transactions consecutively,=0A>each spe= nding m BTC to transaction fees, there is a high probability=0A>that she ha= s given up at least n/2 * m BTC of value. This of course is=0A>all public k= nowledge, recorded in the block chain. It also increases the=0A>transaction= fees for miners, which will be very important for the=0A>network in the fu= ture.=0A>=0A>Now Bob can easily examine the block chain, and upon verifying= Alice's=0A>trust purchase, can decide to accept a zero-confirmation transa= ction at=0A>face value. If Alice breaks that promise, he simply publishes h= er signed=0A>transaction proving that Alice is a fraudster, and future Bob'= s will=0A>distrust Alice's trusted identity, thus destroying the value need= ed to=0A>create it.=0A>=0A>In effect, we now have a distributed green addre= ss system.=0A>=0A>Now Alice could try to mount a double-spend attack on a w= hole bunch of=0A>people at once, hoping to have them all accept the transac= tion. However=0A>as it is the "just trust them" model works pretty well alr= eady.=0A>=0A>=0A>A good usecase for this idea, beyond the obvious fast paym= ents=0A>application, is a distributed anonymizer. Alice can now publish her= =0A>request to anonymize coins, and other trusted identities can make their= =0A>bids. If Alice accepts a bid from Bob, she will want Bob to send her th= e=0A>anonymized coins *prior* to her transaction going through, thus breaki= ng=0A>the temporal connection between the transactions. Now Alice can give = Bob=0A>the signed payment transaction, and Bob can submit his payment=0A>tr= ansaction to the network first, knowing that Alice isn't going to try=0A>to= rip him off. Bob can also have a trusted identity which signed the=0A>cont= ract for the anonymizer transaction, and similarly if he rips Alice=0A>off,= she can publish it for the world to see.=0A>=0A>A more subtle effect, is t= his makes sybil attacks more difficult. To=0A>pretend to be a thousand iden= tities is going to now require 1,000 * n=0A>coins, and attempting to pull t= his attack off inherently strengthens the=0A>bitcoin network. Obviously we = can apply this principle to other things=0A>like tor nodes as well.=0A>=0A>= --=0A>http://petertodd.org 'peter'[:-1]@petertodd.org=0A>=0A>-----BEGIN PGP= SIGNATURE-----=0A>Version: GnuPG v1.4.10 (GNU/Linux)=0A>=0A>iQEcBAEBAgAGBQ= JPmW6EAAoJEH+rEUJn5PoEZfEH/ixptlMX9MzP71bCHMkj7YN1=0A>y6GEkc1vNhyHu01NX77vz= SqR4trbVnWJeJ5hH8EB5tgYRwmI17XoQW6Iz8yEXXgO=0A>JqUKCTBBexGE+F5RfBkizJ9ap5wX= wVrAOIMy/KurSdST+PWMXIPQFaGark01uKcG=0A>M4VXg3U9fc/0Zz1QyKpRTI5O7ZSBqPzEh/X= f4TujR39nUtaI5mkT/bmA3+Te7oRT=0A>34QO7ryF7U001Xz2VJCfm9AE8mPPZjMavLTs/XvPSq= TdliVCZpjGGHzcJ2BPrni5=0A>LEPBsBBxNsuwFGjnRobQwrkPtmYGFntseMLzCJ3iGXWYwedss= Bg2LLOx9QaXG04=3D=0A>=3DPftQ=0A>-----END PGP SIGNATURE-----=0A>=0A>--------= ----------------------------------------------------------------------=0A>L= ive Security Virtual Conference=0A>Exclusive live event will cover all the = ways today's security and=0A>threat landscape has changed and how IT manage= rs can respond. Discussions=0A>will include endpoint security, mobile secur= ity and the latest in malware=0A>threats. http://www.accelacomm.com/jaw/sfr= nl04242012/114/50122263/=0A>_______________________________________________= =0A>Bitcoin-development mailing list=0A>Bitcoin-development@lists.sourcefor= ge.net=0A>https://lists.sourceforge.net/lists/listinfo/bitcoin-development= =0A>=0A>=0A=0A=0A-- =0A=0APeter J. Vessenes=0ACEO, CoinLab=0AM: 206.595.983= 9=0ASkype: vessenes=0AGoogle+ =0A=0A---------------------------------------= ---------------------------------------=0ALive Security Virtual Conference= =0AExclusive live event will cover all the ways today's security and =0Athr= eat landscape has changed and how IT managers can respond. Discussions =0Aw= ill include endpoint security, mobile security and the latest in malware = =0Athreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/=0A___= ____________________________________________=0ABitcoin-development mailing = list=0ABitcoin-development@lists.sourceforge.net=0Ahttps://lists.sourceforg= e.net/lists/listinfo/bitcoin-development=A0