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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W4ZxA-0005MB-9B for bitcoin-development@lists.sourceforge.net; Sat, 18 Jan 2014 17:45:04 +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 1W4Zx6-0001Aq-BK for bitcoin-development@lists.sourceforge.net; Sat, 18 Jan 2014 17:45:04 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Sat, 18 Jan 2014 11:44:52 -0600 id 000000000006A33E.0000000052DABD94.000035EE Date: Sat, 18 Jan 2014 11:44:52 -0600 From: Troy Benjegerdes To: Gregory Maxwell Message-ID: <20140118174452.GG3180@nl.grid.coop> References: <20140113133746.GI38964@giles.gnomon.org.uk> <20140114225321.GT38964@giles.gnomon.org.uk> <20140115230901.GA25135@netbook.cypherspace.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1W4Zx6-0001Aq-BK 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: Sat, 18 Jan 2014 17:45:04 -0000 On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote: > On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman wrote: > > Choosing how many bits to put in the prefix may be difficult, particularly > > if transaction load changes dramatically over time. 0 or 1 bits may be > > just fine for a single user running their own node, whereas a central > > service might want 4 or 5 bits to keep their computation costs scalable. > > Ignoring prefixes the cost for each reusable address is only a small > percentage of the full node cost (rational: each transaction has one > or more ECDSA signatures, and the derivation is no more expensive), so > I would only expect computation to be an issue for large centralized > services. (non-full nodes suffer more from just the bandwidth impact). I have not seen anyone address my high-level question to (somewhat) complicated mechanisms to keep coin flows private. Who pays for it? From what I see it's going to double the amount of data needed per address, further centralizing 'full' nodes. I'm fine if the NSA is paying for privacy (I actually trust them more than banks and advertisers), but let's just be honest, okay? If socializing the cost of privacy is Bitcoin's goal, and giving the benefits to a few that understand it and/or have the resources to determine privacy providers that won't scam them, then say so, so I can get on with launching a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses addresses, and has miners and pools that charge more for addresses they have never seen before. I bet it will be more distributed and have about half the average transaction cost of Bitcoin, because most people *just don't care* about privacy if they get cheap and/or free services. -- Troy, transparency advocate who is quite transparent that if you buy me farmland, I'll shut up about transparency, because I'll be too busy growing food and giving part of it away.