From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UEbTr-0002oB-IS for bitcoin-development@lists.sourceforge.net; Sun, 10 Mar 2013 08:19:43 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UEbTp-0003PF-BS for bitcoin-development@lists.sourceforge.net; Sun, 10 Mar 2013 08:19:43 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r2A8JXKT020019; Sun, 10 Mar 2013 08:19:33 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r2A8JSb7013044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 10 Mar 2013 08:19:30 GMT Date: Sun, 10 Mar 2013 04:18:57 -0400 From: Peter Todd To: Daniel Lidstrom Message-ID: <20130310081857.GA2609@savin> References: <20130307110018.GA7491@savin> <20130307183035.GA9083@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 3bd4a88f-895b-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwIUFVQGAgsB AmUbW1xeUVR7WmI7 bAxPbAVDY01GQQRq WVdMSlVNFUsqA20J fH1MVRlzdAVCfDBx Zk9kWz5YDhB+JE51 FFNcHGhUeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4vFyQz SlUIGTIkHlZNTiM/ ZxcrLEUbBl0RM11a X-Authentic-SMTP: 61633532353630.1019:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.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 X-Headers-End: 1UEbTp-0003PF-BS Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Large-blocks and censorship 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: Sun, 10 Mar 2013 08:19:43 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 07, 2013 at 02:31:10PM -0700, Daniel Lidstrom wrote: > My views on censorship resistance in the face of scaling: >=20 > 1) I expect if I'm not careful about preserving my privacy with the way I > use Bitcoin, then I will always run the risk of being censored by miners. > This means connecting to the network anonymously, not reusing addresses, > and perhaps even mixing my coins. The onus is on me here to avoid > censorship, but I'm optimistic that this privacy preservation can be made > pretty automatic. Yes, but keep in mind the meta risk, which is that as Bitcoin becomes centralized one of the types of transactions that will be censored are ones that preserve your privacy. For instance, as it costs thousands of dollars to setup a mining pool, and hence mining pools also become quite visible, it would be very easy for local governments to start doing things like specifying that transactions must be accompanied with a proof of identification. With that proof of course Bitcoin can remain totally legal, and the pool in business. > 2) I expect anonymity systems to scale to accommodate Bitcoin full nodes, > not Bitcoin to stay small to avoid putting pressure on anonymity systems = to > scale. Why do you expect that? It's always harder to hide a large amount of bandwidth than a small one, and stenography is limited by the bandwidth of the data it's hiding it. HD video streams aren't going to require more bandwidth in the future. > 3) If 2 is too tall an order, then mining in a pool is always an option. > There should always be some countries in the world free enough to allow > mining pools to operate, and miners in countries that ban Bitcoin can > simply connect to these anonymously. If not, then Bitcoin is toast anywa= y, > is it not? If these miners are really interested in avoiding censoring > transactions, then they will do their due diligence and choose a pool that > doesn't do this. But even if they don't, censorship can be personally > avoided by following 1. Right now the thing that keeps pools honest is that setting up another pool is pretty easy; note how most pools are run as hobbyist projects. Similarly you can always use P2Pool, which is totally decentralized. But if running the validating node required to run a pool costs thousands of dollars that competition just isn't there anymore and starting a new pool isn't an option. Remember there will be a chicken and egg problem in that the new pool has thousands of dollars in costs, yet no hashing power yet. As for constantly moving countries, The Pirate Bay is in the same position, and as well as they've done, they still wind up getting shut down periodically. Do you really want access to your funds contingent on some highly visible mining pools, constantly wondering if their local government will change their mind? Anyway, seems that my question was answered: There aren't any clever technical ways to avoid censorship if validating nodes and mining pools are centralized. --=20 'peter'[:-1]@petertodd.org --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRPEHxAAoJEH+rEUJn5PoEOa4H/jUM7308oLofqZqhMjREMcmx iUyd4d0+cqVcm6yTU27TvF5KAJR2R+SLK5ZvzdbD6UijyPLiNY0xnEY9GrQa7vUA +GntLmZ4rOmF0sXFIGj2YyzUaq33MJr27NkNoZcAVOBcFx60/VIf7t3oDkMVJvN/ zU+4fEcBfoehy9mNRfprpJd2AbnAbjEnlUIcNnxqKLl8niAgMP+t7CKSk4eOqvn3 JiRERtZgSTMSkd1WOwbWvZP21jMeFdUHlq50sTFr9ICLceXiq1eQV3r60pR3ncdy fpw6XA2aHiNZVMlb60gBcWh2e+xmqFC4LyhMLK2N+k4NET1AyBf6/j8DUJCMzqE= =ErBP -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb--