From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VeQJI-0001FC-V7 for bitcoin-development@lists.sourceforge.net; Thu, 07 Nov 2013 14:11:49 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] helo=mail.ceptacle.com) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VeQJH-0005uA-33 for bitcoin-development@lists.sourceforge.net; Thu, 07 Nov 2013 14:11:48 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id 86EE1369C59D for ; Thu, 7 Nov 2013 15:11:41 +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 dncFokgj64Dt for ; Thu, 7 Nov 2013 15:11:40 +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 8AE37369C586 for ; Thu, 7 Nov 2013 15:11:40 +0100 (CET) Message-ID: <527B9F9B.4060808@ceptacle.com> Date: Thu, 07 Nov 2013 15:11:39 +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: ethz.ch] X-Headers-End: 1VeQJH-0005uA-33 Subject: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big) 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: Thu, 07 Nov 2013 14:11:49 -0000 Following the discussion on the recent mining sybil trick, I reread the article on block propagation by Decker et al.* and decided to use it for doing a proper estimate of transaction fee size and optimal block size. The propagation of a block depends on and is roughly proportional to its size. Further, the slower a block propagates the higher the risk of a fork, so as a miner you are basically juggling the risk of a fork (meaning you loose your bounty) vs the opportunity for including more transactions and hence also get those fees. This alone will dictate the minimal transaction fee as well as the optimal block size! Lets try to put it into equations. For the purpose of this initial study lets simplify the work by Decker et al. Roughly, we can say that the average propagation time for a block is t_propagate, and the average time between blocks is t_blocks. Those are roughly 10sec and 600sec respectively. The risk of someone else mining a block before your block propagates is roughly**: P_fork = t_propagate/t_blocks (~1/60) Also note that propagation time is a function of block size, S: t_propagate = t_0 + alpha*S where Decker et al have determined alpha to 80ms/kb. We also define the fee size pr kilobyte, f, so E_fee = f*S Given these equations the expected average earning is: E = P_hashrate*(1 - P_fork)*(E_bounty + E_fees) And inserting: E = P_hashrate*[1 - (t_0 + alpha*S)/t_block]*(E_bounty + f*S) We would like to choose the fee so the more transactions we include the more we earn. I.e. dE/dS > 0: dE/dS = P_hashrate*{[(t_block - t_0)*f - alpha*E_bounty]/t_block - 2*alpha*f/t_block*S} Which gives: f > alpha*E_bounty/(t_block-t_0) ~ alpha*E_bounty/t_block or f > 80*25/600000 = 0.0033 or assuming a standard transaction size of 0.227kb: f_tx > 0.00076. Note that this number is 8 times higher than the current transaction fee! So the current optimal block size is an empty block i.e. without other transactions than the coinbase! (miners don't listen now...) Lets see what you loose by e.g. including 1000 transactions: E(1000) = P_hashrate*24.34XBT Which is a loss of 2.6% compared to not including transactions at all! So there are two ways forward from here. 1) raise the minimum fee, and 2) make transactions smaller. We cannot make transactions much smaller, but we can utilize that most of them have already been broadcasted verified and validated and then just include their hash in the block***. This changes the relevant size for a transaction from 0.227kb to 0.032kb. Which makes f_tx = 0.00011. We are almost there! Now assume that we implement this change and raise the minimum fee to 0.00015, what is then the optimal block size (dE/dS = 0) ? S = 1/2 * (t_block/alpha - E_bounty/f) Which gives 1083kb for a bounty of 25 and 2417kb for a bounty of 12.5. Optimal size in case of no bounty or an infinite fee is 3750MB. Final conclusions is that the fee currently is too small and that there is no need to keep a maximum block size, the fork probability will automatically provide an incentive to not let block grows into infinity. *) http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf **) The calculations should be done using the proper integrals and simulations, but I will leave that for academia ;) ***) A nice side effect from switching to broadcasting transactions in blocks as only their hash is that it decouples fee size from transaction size!