From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W3rXV-00044o-PG for bitcoin-development@lists.sourceforge.net; Thu, 16 Jan 2014 18:19:37 +0000 X-ACL-Warn: Received: from nl.grid.coop ([50.7.166.116]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W3rXR-0005YO-Fu for bitcoin-development@lists.sourceforge.net; Thu, 16 Jan 2014 18:19:37 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Thu, 16 Jan 2014 12:19:26 -0600 id 000000000006A33E.0000000052D822AE.00006532 Date: Thu, 16 Jan 2014 12:19:26 -0600 From: Troy Benjegerdes To: Adam Back Message-ID: <20140116181925.GB3180@nl.grid.coop> References: <20140113133746.GI38964@giles.gnomon.org.uk> <20140114225321.GT38964@giles.gnomon.org.uk> <20140115230901.GA25135@netbook.cypherspace.org> <20140116114242.GA30432@netbook.cypherspace.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20140116114242.GA30432@netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.3 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1W3rXR-0005YO-Fu Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 18:19:38 -0000 > >But I think it's great people can choose how to trade privacy for > >computation/bandwidth however they want, and services can compete to > >offer monitoring for 0+ bit prefixes. > > Its not a decision with user localised effect. If most users use it with > parameters giving high elimination probability, that affects everyone else's > privacy also. Also statistical effects are accumulative as more plausibly > related addresses are eliminated at each potentially linked transaction. I > think once the network flow analysis guys are done with incorporating it, > and if reusable addresses saw significant use, my prediction is the result > will be pretty close to privacy game over and it will undo most if not all > of the hard-won privacy benefit of CoinJoin. (Recalling CoinJoin is only > adding a bit or two of entropy per join, this elimination effect could > easily undo more than that). You've got a major social engineering problem here. 1) who is marketing privacy 2) how do you validate 'privacy providers' Just like all the scamcoins, there will be scamprivacy providers, which will drive the market price of privacy down to zero. Who's paying the network/development/bandwidth/etc cost for privacy? I'd guess 85% of real users don't really care about some abstract 'privacy' ideal, they just want payments to work and to download cat pictures. If you say 'regular address re-use is deprecated, and the top 1% in bitcoin weatlh who own 95% of the miners want privacy', well fine. But you just opened yourself up to 'OccupyBitcoin', and an altcoin that ENCOURAGES plain old regular address re-use and transparency. Does this stuff still work if regular address re-use is a transparency feature and not a bug?