17

A pull request on github for dynamic fee calculation was just submitted. How does this new dynamic fee calculation work?

Murch
  • 377
  • 1
  • 12
expez
  • 1,386
  • 10
  • 16

2 Answers2

16

According to the pull request from moneromooo-monero on behalf of ArticMine:

The dynamic fee is based on the block size in a past window, and the current block reward. It is expressed by kB. This function calculates an estimate for a dynamic fee which will be valid for the next grace_blocks

According to dEBRUYNE_1 this change will take effect with v4 in January 2017 and can be represented with the following formula:

The fee will vary based on the base reward and the current

block size limit:

fee = (R/R0) * (M0/M) * F0

R: base reward

R0: reference base reward (10 monero)

M: block size limit

M0: minimum block size limit (60000)

F0: 0.002 monero

According to this recent study, there are some theoretical (but serious) security risks in situations where transaction fees exceed block rewards. (R/R0) will help keep fees in check by reducing them as block reward falls to buffer against this risk.

(M0/M) acts as a sanity check. When blocks are mostly empty it does not make sense to increase the cap. If the network (that previously had relatively empty blocks) is temporarily spammed in order to increase the block size limit, the network does not benefit so the (M0/M) will punish miners by reducing transaction fees. However when legitimate network usage increases over time the amount of increased transactions will compensate for the reduction in transaction fees as the block size cap scales naturally.

With regard to your spam attack tag and how this will change things:

Transaction fees will scale downwards on a per tx basis in the case of an increasing block size limit as the result of the "M" being larger in the (M0/M) part of the equation. However total transaction fees will increase overall as the number of transactions more than cancels out the reduced fee per tx. Spamming the network to increase the block size will remain expensive after this pull request is activated. In addition, for the reason described below such an impact on tx fees would only be temporary.

It is important to note that the (M0/M) portion of new dynamic fee calculation scales in both directions. Appropriate transaction fees differ based on network utilization which is capable of both increasing and decreasing due to countless unpredictable market factors. This new dynamic tx fee formula allows for both upwards and downwards tx fee scaling.

knaccc
  • 8,468
  • 16
  • 22
Peter Karpov
  • 280
  • 2
  • 6
  • You say that the fee will scale upwards if the block size limit "M" increases, but as "M" is in the denominator of the formula, if "M" increases, "M0 / M" decreases, therefore the fee decreases. – glv Oct 30 '16 at 18:09
  • @glv You are right about my numerator and denominator mixup. My description was based on the way I thought it should work which apparently conflicts with that formula. Hopefully someone else can explain why the fee scales in the opposite manner I expected – Peter Karpov Oct 30 '16 at 19:02
  • @glv Maybe my explanation is correct and the formula accidentally swapped the M with M0. I will come back and edit my answer after I know for sure. – Peter Karpov Oct 30 '16 at 19:08
  • 3
    (R/R0) - fee goes down with the reward, but the price should go up long-term. This seems like a good idea considering a recent study showing bad incentives if fee>reward. (M0/M) - fee goes down with the block size cap. So, if the blocks are empty, you lose the fee by increasing the cap. If they're full, you're supposed to reduce the fee/kb, but win more total fees if you increase the block size cap and fill them up until the top. – JollyMort Oct 30 '16 at 21:33
  • @JollyMort that makes sense. I will correct my answer based on that explanation – Peter Karpov Oct 30 '16 at 23:58
  • I take it that the goal is to make the increase good for both miners and users: more total fee/block for the miner, but less fee/kb for the user, while keeping the balance between reward & fee. It will be interesting to see some case study / simulation etc., if anyone will be up for the task. – JollyMort Oct 31 '16 at 08:59
  • Did some simple calculation. min.fee==status quo. x2 min.fee justifies 5% blocksize increase, x5 for 25%. Once blocks expand, if everyone goes back to min. fee, it will be the same total for the miner (no more penalty but min.fee reduced) and now he's 'stuck' with the increased size, otherwise he'd be giving up on fee revenue. – JollyMort Jan 15 '17 at 21:34
  • serious) security risks in situations where transaction fees [revenue] exceed block rewards: my cursory understanding of the research didn’t require transaction fee revenue to exceed block rewards, but rather just become incentives significant perhaps at some fraction of the block reward. Also block reward is declining to eventually minuscule tail reward; thus either you incentivize Sybil attack spam by allowing transaction fee revenue to become tiny (and security also collapses), or you enable the dysfunctionality that the linked research paper explains. Checkmate. I’m not linking 2 my blog – Shelby Moore III Aug 05 '17 at 20:22
  • Correction: I reread the research paper and it clearly states they modeled the case where block rewards decline to zero. Nevertheless I expect that if they modeled any level at which transaction fees become significant to strategic mining incentives, then some of the dysfunction may begin before block reward is zero and possibly even when transaction fees are less than half of the block reward. But I haven’t verified it. – Shelby Moore III Aug 06 '17 at 18:57
  • The M0/M appears to be a bug! Transaction fees should scale proportional to transaction volume, not block size. Otherwise the spammer can make very large transactions (with lower total fees unless minimum fee is accessed per UTXO in the ring and no other way to make large transactions?) to gradually raise the median block size, then employ very small transactions at the much lower minimum fee to more cost effectively spam transactions. In other words cost of raising median block size is lessened, but I guess this isn’t a catastrophic issue. – Shelby Moore III Aug 07 '17 at 04:48
  • There's no bug. It can be rewritten as Fee=(R/M)*0.012; Literal meaning: min. fee is such that it compensates for block reward penalty incurred by expanding the block for 1.2%. – JollyMort Aug 14 '17 at 00:22
0

In the meantime, some more information has been presented here:

How does the dynamic blocksize and the dynamic fees work together in Monero?

JollyMort
  • 19,934
  • 3
  • 46
  • 105