Message-ID: <52860C56.7000608@ceptacle.com>
Date: Fri, 15 Nov 2013 12:58:14 +0100
From: Michael Gronager <gronager@ceptacle.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <528367F5.9080303@ceptacle.com>
	<CAPaL=UWZXSwY9dzX30h_ksj2NAdkyLn3Xtfzs7P8Svg5tsE7Xw@mail.gmail.com>
	<20131115095413.GA17034@savin> <5285FBD9.2070106@ceptacle.com>
	<20131115111204.GF17034@savin>
In-Reply-To: <20131115111204.GF17034@savin>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation
 formula: f > bounty*fork_rate/average_blocksize
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> 

>> Q = Total pool size (fraction of all mining power) q = My mining
>> power (do.) e = fraction of block fee that pool reserves
>> 
> 
> 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.

My Q and q are meant differently, I agree to your Q vs Q-1 argument,
but the q is "me as a miner" participating in "a pool" Q. If I
participate in a pool I pay the pool owner a fraction, e, but at the
same time I become part of an economy of scale (well actually a math
of scale...) and that can end up paying for the lost e. The question
is what is the ratio q/Q where I should rather mine on my own ? This
question is interesting as it will make bigger miners break away from
pools into solo mining, but I also agree that from pure math the most
advantageous scenario is the 100% mining rig.

> 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!

Ha, yes, and then the math for p2pool starts... a math where we have
much more stales...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJShgxWAAoJEKpww0VFxdGRoiwH/3RGTH503PJ8UWuyKjrxscb4
dG3TyThZCDs12DvtC+2TPKnIkQFinGx9442tZU/O+qmwsGJsNVoEcnGmKEYz/vlI
XzFF30ugslB4FKwHZYRqXELaKR4RvUtSzu6td8P3n+e6d0MZsuemMornpbXZkw3n
CbMlYuiG4h3iUAwTaOTS26cFbZoo6eyogydDjnS7Ogi2Ur85Rydi/Lj24rj7UxYB
+WUkYAv3bCqCzTkv1LxO7HwY1SICZDmoGRbuil5M7bJ+MftYt6Q6DVprGSVP0mOV
9eEVeMVY/WmMZCI/01ruXpzC3gxU60vOd/a3q9G2hd9Tn00HzugAllEXh7ZzzUs=
=unP8
-----END PGP SIGNATURE-----