On Fri, Nov 15, 2013 at 11:47:53AM +0100, Michael Gronager wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Peter, > > Love to see things put into formulas - nice work! > > 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 earnings. > > So build your own huge mining data center and you rock. > > However, that is hardly the real work scenario today. Instead we have > pools (Huge pools). It would be interesting to do the calculation: > > Q = Total pool size (fraction of all mining power) > q = My mining power (do.) > e = fraction of block fee that pool reserves > > 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) = 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) = 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) = a-bL you also wind up with mathematica spitting out some truly hideous polynomials. :P Setting f(L) = 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? -- 'peter'[:-1]@petertodd.org 0000000000000000b4ff49cd2cad865d6cbca99828987a02f3d5f41067eab00a
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
