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 1UDYqV-0008F9-5G for bitcoin-development@lists.sourceforge.net; Thu, 07 Mar 2013 11:18:47 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.80 as permitted sender) client-ip=62.13.149.80; envelope-from=pete@petertodd.org; helo=outmail149080.authsmtp.com; Received: from outmail149080.authsmtp.com ([62.13.149.80]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UDYqS-0001fs-IL for bitcoin-development@lists.sourceforge.net; Thu, 07 Mar 2013 11:18:47 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r27B0QLO002235 for ; Thu, 7 Mar 2013 11:00:26 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 r27B0JJX026271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 7 Mar 2013 11:00:21 GMT Date: Thu, 7 Mar 2013 06:00:18 -0500 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20130307110018.GA7491@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 34e5d989-8716-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXwJ1 LRkLXVBSFQZ4AB0L Bh4UUBs8cANYeX5u ZEFqQHFbVVt/fUFi QwAWF2p0ZR0aAGAd VkJfdk1VcQdNflFG bgV6AHoFaHgPYXtm WlZqMmp0N2wHImEN GltQfApJGhlWE2Qq YxkYEjhqF0kCTCYo ZxUgJhYXEUAKNV8p MVo5MQAA 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: 1UDYqS-0001fs-IL Subject: [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: Thu, 07 Mar 2013 11:18:47 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So with UTXO merkle-sum-fee-trees and fraud notices(1) we can effectively audit the blocks produced by miners and provide a way for SPV nodes to reject invalid blocks without requiring the whole blockchain data. Next step: How do we prevent censorship? Can we at all? Basically while UTXO-style proofs allow anyone to determine if a block is valid, it's fundementally still miners that choose what transactions to accept into blocks in the first place. Unfortunately the very nature of a blockchain is that it is meant to prove that transactions are public and that a consensus exists about what transactions are spendable, thus any attempt to hide the bare technical details, txins and txouts, is futile. Even using encryption doesn't work, because assuming you convinced a miner to accept your encrypted transaction, that just shifts the part that makes the transaction public to the act of revealing the key, which again must be done publicly in the blockchain to prove consensus. As transaction volume makes running a validating node more expensive, we can expect the number of independent pools to decrease, or at the very least make monitoring those pools easier as volumes grow beyond what technologies such as Tor can effectively accomodate. This provides the opportunity to pressure the remaining, identifiable, independent miners into accepting restrictions on what transactions can be mined. It's also notably that auditable off-chain transaction systems are vulnerable. All of the trustworthy ones that don't rely on trusted hardware require at least some of their on-chain transactions to be publicly known, specifically so that the total amount of reserves held by off-chain transaction providers can be audited. At best you can use Gregory Maxwell's suggestion of maintaining a "reserve" account backed by funds that rarely move, where new deposits go to non-public addresses and result in the depositor receiving funds from the reserve account, but again, if the spendability of those funds is in question, the value of the reserve itself is also in question. Additionally miners can block fidelity bond sacrifice transactions easily; again a critical technologies required to implement some types of off-chain transaction systems, as well as for many other purposes. Of course we can just assume that the current pseudo-anonymity of transactions is "good enough", but consider the case of stolen coins: even if the bulk of transactions are effectively anonymous, transactions can always be made public delibrately and miners pressured into preventing the movement of coins declared tainted. Finally it's possible that some kind of chaum token system could be implemented directly in the blockchain, but this has the problem that A: no efficient ones are yet known, let alone demonstrated, and B: unless non-chaum token systems are prohibited by a hard-fork with wide adoption, the censorship risk is miners deciding to not mine any chaum token transactions. It's easy to imagine a government deciding that while they will accept transactions that occure on the public block chain, and are thus at best pseudo-anonymous, are acceptable any attempt to conduct truely anonymous transactions will be forbidden. On the other hand, with small blocks the barriers to entry to becoming a miner remain low, and mining anonymously behind low-bandwidth anti-censorship technologies such as Tor remains feasible. Any attempt by a major pool to censor, IE choose not to mine, a transaction will naturally lead to an opportunity for an anonymous miner to get a profit mining that transaction, thus we can expect transactions to be treated fairly equally on a fee per KB basis. In addition, the ever present possibility of this happening, further discourages large miners from doing so in the first place, and in turn gives those miners additional incentive to resist attempts to restrict what transactions they are allowed to mine. Of course off-chain transaction systems can still practice censorship of transactions on their own, but because the decentralized blockchain still exists communities subject to such censorship can always create their own auditable and secure off-chain transaction systems for their own use. Again, the existence of such systems creates economic incentives to find ways to move value between all off-chain transaction systems regardless of imposed restrictions, and again the overall ability to transfer value freely is maintained. 1) https://bitcointalk.org/index.php?topic=3D137933.0 --=20 'peter'[:-1]@petertodd.org --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJROHNBAAoJEH+rEUJn5PoEhekH/1gLeE0TOw8TZ6HRvOOLiUzw 0PGAMvVkWY2BgtL9ERnzrq+7Qq5Vx0cUJPGQbB0WpEualSIYaVO3J8K0weI+CNlU AJQKMM7X6avvZbrIamsdb8ET7/KhOnNBgMqgQFbUiCi1WVLJi+RWvF6xecBxVnyN LdPym4TBkFheW8G7jyZ+pkMG2jI/vqGh+X/KVmlvAwYJZ7BhesNiDlF5eXCqxkdg pMaNsYQdGYMBDqPHo5GSP3xTwG9UM8QdpjP//EnDG4IonYWEAgdHEzjpbODugYGV hvjurRH5fYmvCTePaH9qZ1RAk6qJ6GtYgW0SV790O0h5oeyhhoMQORvPgwKK2C0= =l0c8 -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3--