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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VhHJx-0004wj-Ob for bitcoin-development@lists.sourceforge.net; Fri, 15 Nov 2013 11:12:17 +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 1VhHJw-0004ek-B4 for bitcoin-development@lists.sourceforge.net; Fri, 15 Nov 2013 11:12:17 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id rAFBCA1q001010; Fri, 15 Nov 2013 11:12:10 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 rAFBC5mb093294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 15 Nov 2013 11:12:07 GMT Date: Fri, 15 Nov 2013 06:12:04 -0500 From: Peter Todd To: Michael Gronager Message-ID: <20131115111204.GF17034@savin> References: <528367F5.9080303@ceptacle.com> <20131115095413.GA17034@savin> <5285FBD9.2070106@ceptacle.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ExXT7PjY8AI4Hyfa" Content-Disposition: inline In-Reply-To: <5285FBD9.2070106@ceptacle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: c46fd746-4de6-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwcUFloCAgsB AmUbWlVeUV97WWs7 bAxPbAVDY01GQQRq WVdMSlVNFUsqcGpz dRtDABl7dAdPfDBx YkNnWD4IWEIsIUF5 RFNQQTgAeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4mADM6 DwsDGC0rEFdNQiQ1 Lhk7LxYSEUtZOUw2 OkYlUE4ZNBlwQgNZ BURQBCYLb1dJEWIh Ch5cQV9cHjpHQhBG CwElZRZWDyZbVSdv Dk9CQBIUCjFIOCIS X-Authentic-SMTP: 61633532353630.1024: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 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] X-Headers-End: 1VhHJw-0004ek-B4 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize 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: Fri, 15 Nov 2013 11:12:17 -0000 --ExXT7PjY8AI4Hyfa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 15, 2013 at 11:47:53AM +0100, Michael Gronager wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Peter, >=20 > Love to see things put into formulas - nice work! >=20 > Fully agree on the your fist section: As latency determines maximum > block earnings, define a 0-latency (big-miner never orphans his own > blocks) island and growing that will of course result in increased earnin= gs. >=20 > So build your own huge mining data center and you rock. >=20 > However, that is hardly the real work scenario today. Instead we have > pools (Huge pools). It would be interesting to do the calculation: >=20 > Q =3D Total pool size (fraction of all mining power) > q =3D My mining power (do.) > e =3D fraction of block fee that pool reserves >=20 > It is pretty obvious that given your formulas small miners are better > off in a pool (can't survive as solo miners), but there will be a > threshold q_min above which you are actually better off on you own - > depending also on e. (excluding here all benefits of a stable revenue > stream provided by pools) Unfortunately the math doesn't work that way. For any Q, a bigger Q gives you a higher return. Remember that the way I setup those equations in section 3.2 is such that I'm actually modeling two pools, one with Q hashing power and one with (1-Q) hashing power. Or maybe more accurately, it's irrelevant if the (1-Q) hashing power is or isn't a unified pool. The other thing is the fraction of the block fee the pool reserves indicates you're talking about real-world costs... and the moment you do that you find that pools themselves have economies of scale simply by virtue of using a small overhead infrastructure, their nodes etc., for a large number of miners. On that basis alone a small miner joining a larger pool would always be financially advantageous modulo situations where the large pool had legal restrictions that artificially increased their overheads. > Next interesting calculation would be bitcoin rate as a function of pool > size, I expect a sharp dip somewhere in the 40%s of hardware controlled > by one entity ;) Bitcoin rate? > Finally, as you mention yourselves, qualification of the various > functions is needed. This could e.g. suggest if we are like to get 3 or > 10 miners on the long run. The equations give an incentive to centralize all the way up to 1 miner with 100% hashing power. Of course, if that one pool were p2pool, that might be ok! > And now for section 2. You insert a definition of f(L) =3D a-bL. I think > the whole idea of letting f depend on L is superfluous. As a miner you > are always free to choose which transactions to include. You will always > choose those with the biggest fee, so really it is only the average fee > that is relevant: f(L) =3D c. Any dependence in L will be removed by the > reshuffeling. To include an extra transaction will require either that > it has a fee larger than another (kicking that out out) or that it has a > fee so large that it covers for the other transaction too. Also recall > that there is a logical minimum fee (as I have already shown), and a > maximum optimal block size - that is until the bounty becomes 0 (which > is where other effects kick in). By defining f(L) you can model supply and demand, which can be relevant in that a steep demand curve with a small number of high-fee transactions can reduce centralization pressure in my model. Of course, by defining f(L) =3D a-bL you also wind up with mathematica spitting out some truly hideous polynomials. :P Setting f(L) =3D c as you suggest is something I looked at, and results in equations that are more reasonable, so I think I'll likely wind up doing that. You can make a good argument anyway that the centralization would cause a flattening of any demand curve anyway, as in the no-blocksize-limit case the larger pools cost per transaction tends towards zero as their hashing power increases - why pay high fees when the large pool will mine them almost as fast? --=20 'peter'[:-1]@petertodd.org 0000000000000000b4ff49cd2cad865d6cbca99828987a02f3d5f41067eab00a --ExXT7PjY8AI4Hyfa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGrBAEBCACVBQJShgGEXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDI1YjZhODJkZDcyMTgxMzY5YzI3OTkwOTRiZTNlOGE4MDQ0 YjhiYjk2OTljOTZkMTYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuAxQgAgGqNvC/nxYnAHvY+D1ByWZKE yXPVuytAqKLbHcVJryntw/ZsT4P8XGE0uXZav0USP6Lt9uJDAkAWR+HjDvLfFbC6 SypEgm50kurew+1VOX8Bmnc8w4w9ky5TUR+PL12b9Wn7hbdhkuCvl24P2mxPA4Td CHOP77HgfUrpmIWFui4g/43n+T8vBA7YULnrPVaWMnqSe6QCcF6WrJJVt3IweZ6w 7X+Ex7lxC+i0czkLbIg4sPPDMT87bbSjFCM+0G7jsAPCovnLGJ0VMEJ7kVQjsJeS eV3CjSjyTnwdzdBEY2Le34AXk2ELnOGV69uRvFRjH7qeuogzuUugWxMwWlHW4A== =hbd3 -----END PGP SIGNATURE----- --ExXT7PjY8AI4Hyfa--