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; 
Date: Fri, 15 Nov 2013 06:12:04 -0500
From: Peter Todd <pete@petertodd.org>
To: Michael Gronager <gronager@ceptacle.com>
Message-ID: <20131115111204.GF17034@savin>
References: <528367F5.9080303@ceptacle.com>
	<CAPaL=UWZXSwY9dzX30h_ksj2NAdkyLn3Xtfzs7P8Svg5tsE7Xw@mail.gmail.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)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation
 formula: f > bounty*fork_rate/average_blocksize
Precedence: list


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