From: Michael Gronager <gronager@ceptacle•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
Date: Wed, 13 Nov 2013 13:34:07 +0100 [thread overview]
Message-ID: <528371BF.9030100@ceptacle.com> (raw)
In-Reply-To: <528367F5.9080303@ceptacle.com>
Just a quick comment on the actual fees (checked at blockchain.info) the
average fee over the last 90 days is actually ~0.0003BTC/txn - so not
too far behind the theoretical minimum of 0.00037BTC/txn.
I suppose, though, that it has more to do with old clients and fee
settings (0.0005) than network wisdom ;)
On 13/11/13, 12:52 , 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)".
>
> 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!
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2013-11-13 12:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 11:52 Michael Gronager
2013-11-13 12:34 ` Michael Gronager [this message]
2013-11-15 10:46 ` Peter Todd
2013-11-13 20:01 ` John Dillon
2013-11-13 20:32 ` Michael Gronager
2013-11-15 9:54 ` Peter Todd
2013-11-15 9:59 ` Gregory Maxwell
2013-11-15 10:47 ` Michael Gronager
2013-11-15 11:12 ` Peter Todd
2013-11-15 11:58 ` Michael Gronager
2013-11-15 19:09 ` Peter Todd
2013-11-15 10:32 ` Peter Todd
2013-11-15 11:47 ` Michael Gronager
2013-11-15 19:19 ` Peter Todd
2013-11-20 10:01 ` Peter Todd
2013-11-13 23:52 Gavin Andresen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528371BF.9030100@ceptacle.com \
--to=gronager@ceptacle$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox