Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aeon minimum fee is unfair and arbitrary #213

Closed
ghost opened this issue Feb 12, 2021 · 11 comments
Closed

Aeon minimum fee is unfair and arbitrary #213

ghost opened this issue Feb 12, 2021 · 11 comments

Comments

@ghost
Copy link

ghost commented Feb 12, 2021

When the tail-emission era arrives, block reward is calculated as follows: new_reward = 1.2 * ( x + z ) * ( 2 * x - ( x + z ) ) / ( x ^ 2 ) where x is median block size in kb, and z is the size in kb of the additional transaction to be included above the median.

Now the additional fee that needs to be paid is 1.2 - new_reward to compensate for the miner increasing the size of the block.
So the fair fee_per_kb is this fee divided by the tx size z.
Finally the formula for fee_per_kb is (1.2 - 1.2 * ( x + z ) *( 2 * x - ( x + z ) ) / ( x ^ 2 )) / z or quite simply

fee_per_kb = 1.2 z / ( x ^ 2 )

Now we can see the fair fee_per_kb depends on two variables:

  1. the size of the additional transaction z
  2. the current median limit x

The amount 0.001 is unfair to miners and network participants.

We can take z to be 1kb. With the current median limit of 19.53kb, the fair fee_per_kb is then 1.2 * 1 / ( 19.53^2 ) = 0.00314 which is 3x higher than the current imposed fee minimum. This means that miners will generally incur a penalty for increasing the block size.

If AEON should ever approach 1MB/10min like bitcoin that is a median limit of ~400kb which gives a fair fee_per_kb of 1.2 * 1 / ( 400^2 ) = 0.000075. That is 7.5% of the current minimum fee. Network participants will be paying far too high. Miners can afford to rapidly increase the median limit.

That is why a fixed minimum fee_per_kb is unfair to both miners and network participants. It should vary as the inverse of the square of the median block size.

the fee per kb is arbitrary and dangerous

It is only a fair fee when the median is about 50-100kb. Any median above that, network participants are paying too high. If we are going to pick an arbitrary constant, why not pick something based on a block size such as 1MB/10min = 400kb. Then the minimum fee should be 0.000075-0.00075. AEON transactions may be larger on average than bitcoin. A higher target block size may be more appropriate.

Secondly it establishes a fixed value for AEON; that is .001 AEON = 1 kb. That is not something we should hardwire into the protocol. Fees should be allowed to vary as long as they satisfy the compensation for the miners. It is not advisable to establish a arbitrary peg to which AEON can be compared at the protocol level.

Finally, the only constant in this equation should be the estimated size of a transaction z which is the transaction size in kb NOT the fee_per_kb. As blocks grow, the cost of one additional transaction is less to miners and it should be less for network participants. Not only that, if the fee_per_kb varies as inverse of median squared, as more transactions are processed, fees will go down!

Thank you for reading. Please consider this proposal.

@ghost
Copy link
Author

ghost commented Feb 13, 2021

Here is the simplest solution:

miner_penalty = min_fee_per_kb * kb_above_median

min_fee_per_kb = 1.2 / median_block_limit

Notice the total fees per block remains on average a constant value. I have chosen 1.2 as that is a constant already present in the protocol as the tail block reward and will likely represent a significant amount in the future to prevent spam.

  • Where is the incentive for miners?

Any tx with fees above the min_fee_per_kb will incentivize miners to increase block size as they will receive the bonus fees above the total 1.2 coins. This will arise naturally from demand.

If miners fill blocks with dummy tx, they will ultimately drive fees down as the average total fees per block remains constant, users will pay less and less fees as they are utilizing a smaller proportion of block space. Miners will earn less and from each block if they continue to push the block size larger.

Miners can expect a constant return from tx fees each block forever. I have chosen 1.2 aeon coins as that seems an appropriate amount given that it is the chosen tail emission.

  • Where is the incentive for users?

Market driven fee discovery on demand.
Fees decrease per kb as block size increases. 👍

  • What fees can we expect?

Right now the median_block_limit is 20,000 bytes = ~19.53kb. We can begin at this level even, taking the min_fee_per_kb to be 1.2/19.53 = 0.06144. That makes for tx fees to be between 0.6 and 0.06 aeon coins.

If AEON achieves 1MB/10min such as Bitcoin, that is ~400kb median limit. That gives us 1.2/400kb = 0.003 min_fee_per_kb

  • What are the limitations?

If blocks grow to be too large, the fee will tend to zero. The smallest min_fee_per_kb can be is 10^-12 or 1 atomic unit for a 1kb transaction. That means the median block size is 1.2*10^12 kb, about 1 petabyte and a trillion transactions per second. Wow! I hope we find that some day.

I think this is the fairest solution. Please share your thoughts.

@iamsmooth
Copy link

Your penalty formula appears to linear, which incentivizes miners to pack as many txs into the block as possible as long as those transactions pay a fee infinitesimally above the minimum. This would allow users to spam the blockchain and grow the block size (and therefore the blockchain) to an unmanageable level very rapidly. The quadratic penalty is intended to encourage only increasing the block size by a small amount over the median UNLESS there is extremely high short term demand.

@iamsmooth
Copy link

Oh and I agree the minimum is arbitrary and should be changed. It's largely an anti-spam feature for p2p and doesn't work out if the blocks grow very large and/or the price of AEON is very high. I believe Monero does something different but I don't remember exactly how it works. I think we picked the fixed amount as just being simple (including easy for users to understand) and workable for the intermediate term.

@ghost
Copy link
Author

ghost commented Feb 13, 2021

Yup I have come to that conclusion as well. Penalty needs to grow following some higher order function. I am going to forget monero for now maybe come back to it later. I believe they are still using hardcode constant for min fee that needs to be changed. I think it is better to create something that is future proof so better to use clean slate.

So I did study on what is fair total fees

here are some numbers for other coins. Not directly comparable but gives an idea:

Bitcoin : 1 Y fees = .1% of supply
DOGE: 1 Y fees = .01% of supply
DASH: 1 Y fees = .01% of supply
LTC/XMR: 1 Y fees = .0075% of supply

Using supply and median block size, we can get the fair fee per byte. supply * 0.01% / blocks per year = ~ 18.4 million * .0001 / 131400 = 1.4 * 10^-8 .

So based on this min_fee_per_kb = 1.4 * 10^-8 / median_limit_kb. Then miners can expect average 1840 coins per year in fees.

=============

Now for all of the penalty dynamics. You are sharing a few important scenarios which need to be solved:

  1. miners need incentive to increase blocksize
  2. users should not be able to spam block size limit or it should be expensive at a rate equal to the growth.
  3. fees remain mostly non-competitive for users.

I am going to think about this and come back. It may have to be more creative. With fixed fees, dynamics have changed slightly. For example, a user attacker will incur a fixed cost: the block reward plus fixed total fees while also increasing blocks exponentially. That is what is useful about a fixed minimum fpb as it allows the total fees to increase. I think the fixed total fee is better and possible. There may need to be a tighter bound on median limit increases such as (m+1)/m instead of 2m

@iamsmooth
Copy link

Monero doesn't use the hard coded fee any more. It has something based on the block size that I believe is described here, although it is possible this is out of date. stackexchange

Sorry, didn't have time to read the rest of your comment, will get back to it later.

@iamsmooth
Copy link

iamsmooth commented Feb 13, 2021

  1. You also need a minimum fee for p2p purposes otherwise users can spam the network and nodes' memory pools without risking having to pay much. Bitcoin handles this in a dynamic manner (nodes set a maximum memory pool size and start rejecting the cheapest transactions once the allotted memory is full) which seems to work okay but is complicated. Monero and AEON use semi-static (Monero's adjusts to block size) minimums that serve the same essential purpose but probably works less well in the sense of not getting in the way beyond the essential purpose.

@ghost
Copy link
Author

ghost commented Feb 14, 2021

Thanks for the comments/review, yes after reading again ArticMine implementation is exactly what I am suggesting even 0.01% supply per year.

I would add small modification to make blocks size change slower. doubling time of 100 blocks is too small especially for 2 min block time. In one day, the block size can increase 150x. That does not seem very good as far as blockchain bloat or privacy concerns. for 4 min blocks we can see x12 per day not bad but I think <= x2 per day is better off AKA median (why median and not average?) taken over past 720 blocks.

did find this discussion from rebase #4 (comment) if it is ever useful. May be simple to implement with that if it becomes necessary in future.

@ghost
Copy link
Author

ghost commented Feb 16, 2021

Imagine this attack scenario for monero:

Fill block with min fee tx : fixed cost ~ 0.03 xmr
Cover miner penalty : fixed cost ~0.6 xmr
Give incentive for miner : fixed cost say ~ 0.07 xmr

Total cost for a 2x block : 0.7 xmr

Block size increases 2x every 50 blocks. That will cost less than 0.7 * 50=35 monero to double block size. With 32*35=1120 xmr you can increase blocksize by 2^32 in just 53 hours.

I think the problem here is the fixed cost. That is due to the fixed reward+ fixed fees. So one solution is to start off with sufficiently high fees and longer doubling time. Then total fees can be reduced slowly over time as they are more widely distributed such as a halving schedule every so many years.

@ghost
Copy link
Author

ghost commented Feb 16, 2021

I estimate doubling time of 360 blocks (taking median over past 720 blocks) and 2^36 atomic unit fees per block would be good to start. Not far from where we are today. That makes 456.739011625 coin cost for doubling block size. cost = 360*(1.2+fee_per_block+incentive)

min_fee_per_kb = (2^36/ 10^12) / median_720_kb

same penalty and 2x limit.

median taken over 720 blocks.

I would suggest halving fees every four years until it is satisfactory low such as 2^16 au per block. The attack cost is largely determined by miner reward and number of blocks not the fees.

@BigslimVdub
Copy link

TLDR: if you allow miners to pick fees they will spam the blockchain to increase their revenue bloating the chain for everyone else.

I think the only reason to change the current structure would be to allow persons with higher tx speed requirements to always be kept in highest priority. As of right now if there are many blocks in the mempool and you send a large size high fee tx, it will usually be pushed back in priority. It seems that this proposed change would potentially fix this and always push high fee tx to the front unless, like Bitcoin and all others, everyone is sending high fee tx in which case the change would only benefit miners (enter ETH here).

@ghost
Copy link
Author

ghost commented Feb 22, 2021

Yup that settles it.

@ghost ghost closed this as completed Feb 22, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants