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 1U7TUV-00073B-1q for bitcoin-development@lists.sourceforge.net; Mon, 18 Feb 2013 16:22:55 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.55 as permitted sender) client-ip=62.13.149.55; envelope-from=pete@petertodd.org; helo=outmail149055.authsmtp.co.uk; Received: from outmail149055.authsmtp.co.uk ([62.13.149.55]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1U7TUO-0006NR-5a for bitcoin-development@lists.sourceforge.net; Mon, 18 Feb 2013 16:22:55 +0000 Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226]) by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r1IGMdh4034530; Mon, 18 Feb 2013 16:22:39 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 r1IGMX3g008353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2013 16:22:36 GMT Date: Mon, 18 Feb 2013 11:22:35 -0500 From: Peter Todd To: Stephen Pair Message-ID: <20130218162235.GA17224@savin> References: <20130214060744.GA15157@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 684005fd-79e7-11e2-98a9-0025907ec6c5 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwoUHlAWAgsB AmUbWlJeUl97WmU7 bAxPbAVDY01GQQRq WVdMSlVNFUsqAGV2 e3YdBRlyfwZDezBy bEZkWj5dVEB6dUMr FlNTHDgBeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4qGDU7 XQgFBzwzHEsKDy83 KBclYkAVGEcdO1kz Nl1pQ08cPn1aDwpS Hk9MCyZFJl4HXGIq Cx9dFVIeHXVXRSBX AVUjIhZJBFQA X-Authentic-SMTP: 61633532353630.1020: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 0.0 LOTS_OF_MONEY Huge... sums of money X-Headers-End: 1U7TUO-0006NR-5a 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: Mon, 18 Feb 2013 16:22:55 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2013 at 07:59:04AM -0500, Stephen Pair wrote: > > 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. > > >=20 > Perhaps, but a miner trying to target just over 50% of the network will r= un > the very real risk that they'll only reach 49%. Then don't be so agressive; target 90% as I suggested and the miner still comes out ahead by having 10% less hashing power to compete with. 50% is only a maximum because when more than 50% of the network does not see your blocks the majority will inevitably create a longer chain than you, but less than 50% and your part of the network will inevitably create a longer chain than them. > What about the case for centralization if the block size remains capped? = I > see a far greater risk of centralization in that scenario than if the cap > were to be removed. The reason is very simple, bitcoin would ultimately > become useful only for very high value, settlement transactions. Only the > mega corporations and banks would be using it directly, everyone else wou= ld > be doing daily transacting in centrally issued currencies of one form or > another. As the banks and mega corps learned about the utility of bitcoin > and began to use it en masse, they would start to take the whole network > off the public internet and put it on a higher speed and more reliable > backbone. Those corporations would establish mining agreements among > themselves to ensure none of the participants could take over the system > and compromise it, while at the same time keeping the operational costs to > a minimum. Bitcoin is now a great alternative to the wire transfer syste= m, > but has no value to the average person wanted to have cheap and private > transactions over the Internet. Maybe Litecoin starts to fill that niche. What you are describing is either *voluntary* centralization, or won't happen. Nothing in your scenario will stop people from transacting on the Bitcoin network directly, it will just make it more expensive. For instance suppose fees rose to the point where the value of the fees was 10x the value of the block reward today; miners would be taking in $972,000/day, or $6750/block. At 1MiB/block that implies transaction fees of $6.75/KiB, or about $2 per transaction. Even if the fees were $20 per transaction that'd be pretty cheap for direct access to the worlds bank-to-bank financial network; I can still transfer an unlimited amount of money across the planet, and no-one can stop me. Importantly there will be plenty of demand to have transactions mined from people other than banks and large corporations. Because there will continue to be demand, and because 1MiB blocks means running a relay node is trivial enough that people can do it just for fun, banks won't be able to force people to use their "high-speed backbone". Not to say they won't create one, but it won't have any real advantage over something that can be run in your basement. On the mining side with 1MiB blocks the fixed costs for setting up a mining operation are just a moderately powered computer with a bunch of harddrive space and a slow internet connection. The marginal costs are still there of course, but the cost of power and cooling are lower at small scale than at larger industrial scales; power is often available for free in small amounts, and cooling isn't a problem in small setups. Because small-scale miners will still exist, there will still be a market for "consumer" mining gear, and trying to regulate mining equipment will just turn it into a black-market good. Small blocks let you setup a mining operation anywhere in the world - good luck controlling that. Mining also will remain a way to import Bitcoins into places. Banks can try setting up exclusive mining contracts, but unless they control more than 50% of the network they'll still have to accept blocks found by these highly decentralized, small-scale miners. They'd be better off broadcasting their transactions to those miners as well so they don't get double-spent. Thus decentralized miners still can profit =66rom transaction fees, and still have an incentive to mine. Doesn't sound like centralization to me at all. On the other land, with large blocks, not only is mining solo unprofitable due to the huge fixed costs required to process the blocks, miners on pools can't effectively secure the network because they can't independently verify that the blocks they are mining are valid. It would be easy then to co-opt the relatively small number of pools, a number that is not particularly large even now. Transaction relay nodes would also be very expensive to run, and again the small number of them makes them targets for control. Sure transactions will be cheap, but that doesn't do you any good if the small number of miners out there are all regulated and ignore your transactions. Sounds like centralization to me. --=20 'peter'[:-1]@petertodd.org --FCuugMFkClbJLl1L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRIlVKAAoJEH+rEUJn5PoE+ScH/RYpWqcK3WauvNCodaAEceFU DCp+fJuFHn0Mftw5IIpMzkekZEVaRo+tNTgbF9WGE9WTZttAXpHWiGRyaz5b2yV6 1ru5D/qnBtFOB8K8M2onYp5+R6IbCIKSCXNbZ5YfDqQDIBvrSaJW6qDHi7Q5ndDN E9BPXV2xPAc1tfiDSTawrHKayoqP2PWdi+DENgEktAVAEVjYzo2jHEvf5bZ+jAZy lp0/UjqAKE9pJBxzrK4LstRL1v7IsjCxzhRROEgcJt1QvqdTdH6z7zls55XFvw+F auGQ4RRmwsAVNup22kvSfcDiadvPEZW5hsCbVjKlRZCzmmVsx49Axb/Bw1NksEg= =M31Z -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L--