Michael Gronager [ARCHIVE] on Nostr: š Original date posted:2013-11-13 š Original message:Last week I posted a ...
š
Original date posted:2013-11-13
š Original message: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!
š Original message: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!