Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.77 as permitted sender)
	client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
	helo=outmail149077.authsmtp.com; 
Date: Fri, 15 Nov 2013 05:32:46 -0500
From: Peter Todd <pete@petertodd.org>
To: Michael Gronager <gronager@ceptacle.com>
Message-ID: <20131115103246.GB17034@savin>
References: <528367F5.9080303@ceptacle.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR"
Content-Disposition: inline
In-Reply-To: <528367F5.9080303@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


--6sX45UoQRIJXqkqR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 13, 2013 at 12:52:21PM +0100, Michael Gronager wrote:
> Last week I posted a writeup: "On the optimal block size and why
> transaction fees are 8 times too low (or transactions 8 times too big)".
>=20
> Peter Todd made some nice additions to it including different pool sizes
> into the numbers.
>=20
> However, it occurred to me that things can in fact be calculated even
> simpler: The measured fork rate will mean out all the different pool
> sizes and network latencies and will as such provide a simple number we
> can use to estimate the minimum fee. Key assumption is that the latency
> will depend on block size (# txns) and the fork rate will depend on laten=
cy.
>=20
> Using the formulas from last week:
>=20
> P_fork =3D t_propagate/t_blocks
>=20
> and:
>=20
> t_propagate =3D t_0 + alpha*S ~=3D alpha*S

Assuming t_0 is negligible is wrong in this case. Or, it should be...

> We get a measure for alpha as a function of the average fork rate and
> average block size:
>=20
> alpha =3D P_fork*t_block/S

So alpha has units of seconds/byte, which lets us indirectly figure out
the bandwidth the blocks are propagating at assuming t_0=3D0 and all links
are equal. When you realize that P_fork is basically a multiplier on the
bandwidth required to get a block out fast enough, the derivation makes
sense. In any case we get:

alpha =3D (1/113)*600s/134kBytes =3D 39.62uS/byte =3D 24kB/second

Which is atrocious... but when you remember that Bitcoin nodes send
blocks to all peers simultaneously,(1) thus dividing up the bandwidth and
ruining latency you see why. t_0 shouldn't be at all negligible due to
speed of light, but with this low bandwidth it is anyway.

1) To be precise, nodes answer queries for blocks from all peers
simultaneously.

This also indicates that pools haven't taken the simple step of peering
with each other using high-bandwidth nodes with restricted numbers of
peers, which shows you how little attention they are paying to
optimizing profits.  Right now mining pulls in $1.8 million/day, so
that's up to $16k wasted.

However, because miners don't orphan themselves, that $16k loss is born
disproportionately by smaller miners... which also means the 24kB/sec
bandwidth estimate is wrong, and the real number is even worse. In
theory anyway, could just as easily be the case that larger pools have
screwed up relaying still such that p2pool's forwarding wins.

--=20
'peter'[:-1]@petertodd.org
000000000000000658459cd64e63243e719106014257870d073207c2d5460137

--6sX45UoQRIJXqkqR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGrBAEBCACVBQJShfhOXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDc1ZWQ5MTUzMWUwN2QyMDQ1YjU4MjNkYTA1MGZlMzczYmRl
N2JiMzYzOTY1ZTQ0YWUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfurJwgAptj95GdOX0/cedNBfi2D1tAx
jfEFWFJXs497eh8DIcH6Fvl6qF6U+b//kX9Fsi3FuTBywdYSYcJmyfyWyeX7zELD
xZZeoOg0TETtHuGK0DA7h0I89MfP5rnxoRrQYHk3SP8MSoZIHbI+B7PA8VXd1olH
foPav+98SNsfQzHgO4uSuyqsjkCc5oFeaYeSMQ+TJz2RNgApwGr+HqCxq/oIA9ZJ
82n0yHmBEEnMqKzZ3Z9T1n5C2BIDQy0WL3jQMwADRfFQ1JhyBWEGefBXY4ee3isU
5nf7eprYS7GbteNANaHhijlgZQoCLb5HO0+kk5l7ejMNhrh58LzZx5G5cRc6Cg==
=aDyD
-----END PGP SIGNATURE-----

--6sX45UoQRIJXqkqR--