From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VgYzp-0005ax-9f for bitcoin-development@lists.sourceforge.net; Wed, 13 Nov 2013 11:52:33 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] helo=mail.ceptacle.com) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VgYzl-0003XH-6h for bitcoin-development@lists.sourceforge.net; Wed, 13 Nov 2013 11:52:33 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id 08F1B36E4CEC for ; Wed, 13 Nov 2013 12:52:23 +0100 (CET) X-Virus-Scanned: amavisd-new at ceptacle.com Received: from mail.ceptacle.com ([127.0.0.1]) by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFtCOY5WP571 for ; Wed, 13 Nov 2013 12:52:22 +0100 (CET) Received: from MacGronager.local (cpe.xe-3-1-0-415.bynqe10.dk.customer.tdc.net [188.180.67.254]) by mail.ceptacle.com (Postfix) with ESMTPSA id 1781836E4CD4 for ; Wed, 13 Nov 2013 12:52:22 +0100 (CET) Message-ID: <528367F5.9080303@ceptacle.com> Date: Wed, 13 Nov 2013 12:52:21 +0100 From: Michael Gronager 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 Dev X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 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: blockchain.info] X-Headers-End: 1VgYzl-0003XH-6h Subject: [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: Wed, 13 Nov 2013 11:52:33 -0000 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)". Peter Todd made some nice additions to it including different pool sizes into the numbers. 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 latency. Using the formulas from last week: P_fork = t_propagate/t_blocks and: t_propagate = t_0 + alpha*S ~= alpha*S We get a measure for alpha as a function of the average fork rate and average block size: alpha = P_fork*t_block/S Further, take the formula for the minimum fee: f > alpha*E_bounty/t_block And insert the formula for alpha: f > P_fork*E_bounty/S_average Luckily the fork frequency and the average block size are easily measurable. blockchain.info keeps historical graphs of number of orphaned blocks pr day - average over the last year is 1.5. Average number of blocks per day over the last year is 169, which yields a P_fork of ~1/113. Average block size in the same time is 134kBytes, which yields a minimum fee: f > 0.00165XBT/kb or 0.00037XBT/txn So the 0.0001 is only 4 times too small. Further, let us look at the trend over the last 12 months. Pieter Wuille claimed that there has been several improvements over the last half year that would bring down the latency, there has also been speculations regarding direct connections between the major pools etc - lets see if this is indeed true. If you look instead of 360 days, only at the last 90 days the average block size has been 131kBytes, and the fork rate has been ~1/118, which results in a minimum fee of: f > 0.00162XBT/kb or 0.00037XBT/txn So a small improvement but not statistically important... Last question, recalling that optimal revenue block size is a function of the txn-fee (from the last writeup) - lets see what fee it takes to support a block size of 131kBytes: S = 1/2 * (t_block/alpha - E_bounty/f) S = 1/2 * (S/P_fork - E_bounty/f) f = E_bounty/[(1/P_fork-2)*S] = 0.00165XBT/kB So a 4 times increase is still sufficient for the current load. Anyway - the all important number is alpha, the network latency which we expect to be dependent of various things such as interconnectivity, bandwidths, software quality etc, where mainly the latter is within our hands to bring down the fee. And you can actually setup the standard client to choose a better fee, as all the parameters in the formula are easily measured!