From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VeR45-0001KQ-0f for bitcoin-development@lists.sourceforge.net; Thu, 07 Nov 2013 15:00:09 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.174 as permitted sender) client-ip=209.85.223.174; envelope-from=pieter.wuille@gmail.com; helo=mail-ie0-f174.google.com; Received: from mail-ie0-f174.google.com ([209.85.223.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VeR43-000549-AF for bitcoin-development@lists.sourceforge.net; Thu, 07 Nov 2013 15:00:08 +0000 Received: by mail-ie0-f174.google.com with SMTP id qd12so954564ieb.19 for ; Thu, 07 Nov 2013 07:00:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.16.68 with SMTP id e4mr2360741igd.12.1383836401496; Thu, 07 Nov 2013 07:00:01 -0800 (PST) Received: by 10.50.141.136 with HTTP; Thu, 7 Nov 2013 07:00:01 -0800 (PST) In-Reply-To: <527B9F9B.4060808@ceptacle.com> References: <527B9F9B.4060808@ceptacle.com> Date: Thu, 7 Nov 2013 16:00:01 +0100 Message-ID: From: Pieter Wuille To: Michael Gronager Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) 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: doubleclick.net] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VeR43-000549-AF Cc: Bitcoin Dev Subject: Re: [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 15:00:09 -0000 Hi, (I didn't have time to read your e-mail entirely yet, I'll do so later) I believe that C. Decker's paper used measurements for propagation delays for blocks 180000-190000, which happened between may and juli 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3. I'm sure the general patterns are valid, but if you're relying on actual speed numbers, I believe they may be very different now. I don't have numbers of course, but at least the changes 0.8 should impact propagation significantly. Some changes merged in git head (to become 0.9) could improve things further. If we're talking about long-term scalability, we should base decisions on the best technology available, at least. -- Pieter On Thu, Nov 7, 2013 at 3:11 PM, Michael Gronager wrote: > 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! > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development