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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U5rzY-0001Zx-6M for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 06:08:20 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.113 as permitted sender) client-ip=62.13.148.113; envelope-from=pete@petertodd.org; helo=outmail148113.authsmtp.com; Received: from outmail148113.authsmtp.com ([62.13.148.113]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1U5rzU-0003Gg-WD for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 06:08:20 +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 r1E688d5031959; Thu, 14 Feb 2013 06:08:08 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 r1E682qO032896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 06:08:04 GMT Date: Thu, 14 Feb 2013 01:07:44 -0500 From: Peter Todd To: Stephen Pair Message-ID: <20130214060744.GA15157@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: e5bdb601-766c-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwYUHlAWAgsB AmUbW1JeUFV7WWY7 bAxPbAVDY01GQQRq WVdMSlVNFUsqAGkH DhxfLRlxdQ1PfjBy bU9gWj4OWRYuJ0B9 Q1NTE2tVeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4qGDU7 XQgFBzwzHEsKDy83 KBclYkAVGEcdO1kz Nl1pQ08cPn1aDwpS Hk9MCyZFJl4HXGIq Cx9dFVIeHXVXRSBX AVUjIhZJBFQA 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: 1U5rzU-0003Gg-WD Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain 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, 14 Feb 2013 06:08:20 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 09:44:11PM -0500, Stephen Pair wrote: > One of the beauties of bitcoin is that the miners have a very strong > incentive to distribute as widely and as quickly as possible the blocks > they find...they also have a very strong incentive to hear about the bloc= ks > that others find. There will not be an issue with blocks being "jealously The idea that miners have a strong incentive to distribute blocks as widely and as quickly as possible is a serious misconception. The optimal situation for a miner is if they can guarantee their blocks would reach just over 50% of the overall hashing power, but no more. The reason is orphans. Here's an example that makes this clear: suppose Alice, Bob, Charlie and David are the only Bitcoin miners, and each of them has exactly the same amount of hashing power. We will also assume that every block they mine is exactly the same size, 1MiB. However, Alice and Bob both have pretty fast internet connections, 2MiB/s and 1MiB/s respectively. Charlie isn't so lucky, he's on an average internet connection for the US, 0.25MiB/second. Finally David lives in country with a failing currency, and his local government is trying to ban Bitcoin, so he has to mine behind Tor and can only reliably transfer 50KiB/second. Now the transactions themselves aren't a problem, 1MiB/10minutes is just 1.8KiB/second average. However, what happens when someone finds a block? So Alice finds one, and with her 1MiB/second connection she simultaneously transfers her new found block to her three peers. She has enough bandwidth that she can do all three at once, so Bob has it in 1 second, Charlie 4 seconds, and finally David in 20 seconds. The thing is, David has effectively spent that 20 seconds doing nothing. Even if he found a new block in that time he wouldn't be able to upload it to his other peers fast enough to beat Alices block. In addition, there was also a probabalistic time window *before* Alice found her block, where even if David found a block, he couldn't get it to the majority of hashing power fast enough to matter. Basically we can say David spent about 30 seconds doing nothing, and thus his effective hash power is now down by 5% However, it gets worse. Lets say a rolling average mechanism to determine maximum block sizes has been implemented, and since demand is high enough that every block is at the maximum, the rolling average lets the blocks get bigger. Lets say we're now at 10MiB blocks. Average transaction volume is now 18KiB/second, so David just has 32KiB/second left, and a 1MiB block takes 5.3 minutes to download. Including the time window when David finds a new block but can't upload it he's down to doing useful mining a bit over 3 minutes/block on average. Alice on the other hand now has 15% less competition, so she's actually clearly benefited from the fact that her blocks can't propegate quickly to 100% of the installed hashing power. Now I know you are going to complain that this is BS because obviously we don't need to actually transmit the full block; everyone already has the transactions so you just need to transfer the tx hashes, roughly a 10x reduction in bandwidth. But it doesn't change the fundemental principle: instead of David being pushed off-line at 10MiB blocks, he'll be pushed off-line at 100MiB blocks. Either way, the incentives are to create blocks so large that they only reliably propegate to a bit over 50% of the hashing power, *not* 100% Of course, who's to say Alice and Bob are mining blocks full of transactions known to the network anyway? Right now the block reward is still high, and tx fees low. If there isn't actually 10MiB/second of transactions on the network it still makes sense for them to pad their blocks to that size anyway to force David out of the mining business. They would gain from the reduced hashing power, and get the tx fees he would have collected. Finally since there are now just three miners, for Alice and Bob whether or not their blocks ever get to Charlie is now totally irrelevant; they have every reason to make their blocks even bigger. Would this happen in the real world? With pools chances are people would quit mining solo or via P2Pool and switch to central pools. Then as the block sizes get large enough they would quit pools with higher stale rates in preference for pools with lower ones, and eventually the pools with lower stale rates would probably wind up clustering geographically so that the cost of the high-bandwidth internet connections between them would be cheaper. Already miners are very sensitive to orphan rates, and will switch pools because of small differences in that rate. Ultimately the reality is miners have very, very perverse incentives when it comes to block size. If you assume malice, these perverse incentives lead to nasty outcomes, and even if you don't assume malice, for pool operators the natural effects of the cycle of slightly reduced profitability leading to less ability invest in and maintain fast network connections, leading to more orphans, less miners, and finally further reduced profitability due to higher overhead will inevitably lead to centralization of mining capacity. --=20 'peter'[:-1]@petertodd.org --liOOAslEiF7prFVr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRHH8vAAoJEH+rEUJn5PoE9bwH/3JUYA026jqy9VX8hO8csC7t 7Lyuw/cgTLqeW2e2Im7CTh6vOwg3uZSBOb41lnE5fy+Lj+Rg84dGkpUBrjYVd5zM BtcNlwgKKnZfehMRv2NUs/hjrobGPathPMJW/M0OsMZKBxT1iJFBi/A/EoR58b6L QBBYmIcwxHDVP0ru4EJOW+zBbZR5XobH4Eev9K86IIulQ4VKezY0wOpBRKqZ7dX/ K8jbiGNwnR4Fg3QSIHRKnktpckPq3DaVPbk1Df552cGHDGfLKMH+l08Td04xCK8C f+hKOXBSFDp499nX05BcCjsvE3P2GJ2qxs7maRpNO5jRERhxp1ZKNjXpr+NXtNY= =Lkx4 -----END PGP SIGNATURE----- --liOOAslEiF7prFVr--