From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VhGiS-0006bI-M9 for bitcoin-development@lists.sourceforge.net; Fri, 15 Nov 2013 10:33:32 +0000 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; Received: from outmail149077.authsmtp.com ([62.13.149.77]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VhGiR-0004wP-FZ for bitcoin-development@lists.sourceforge.net; Fri, 15 Nov 2013 10:33:32 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rAFAWpsN085373; Fri, 15 Nov 2013 10:32:51 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 rAFAWlkC075360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 15 Nov 2013 10:32:50 GMT Date: Fri, 15 Nov 2013 05:32:46 -0500 From: Peter Todd To: Michael Gronager 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) X-Server-Quench: 4776d3a5-4de1-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwcUFloCAgsB AmUbWlReU197XGI7 bAxPbAVDY01GQQRq WVdMSlVNFUsqcGpw YUJFIRl1cgZAeDBx Z0VhWD5fW0N8IUUs R1NQQTgHeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4mADM6 DwsDGC0rEFdNQiQ1 Lhk7LxYSEUtZOUw2 OkYlUE4ZNBlwQgNZ BURQBCYLb1dJEWIh Ch5cQV9cHjpHQhBG CwElZRZWDyZbVSdv Dk9CQBIUCjFIOLUD X-Authentic-SMTP: 61633532353630.1023: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] 0.0 LOTS_OF_MONEY Huge... sums of money X-Headers-End: 1VhGiR-0004wP-FZ 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 10:33:32 -0000 --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--