-
Notifications
You must be signed in to change notification settings - Fork 43
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
Comments
Here is the simplest solution:
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.
Any tx with fees above the 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.
Market driven fee discovery on demand.
Right now the If AEON achieves 1MB/10min such as Bitcoin, that is ~400kb median limit. That gives us 1.2/400kb = 0.003
If blocks grow to be too large, the fee will tend to zero. The smallest I think this is the fairest solution. Please share your thoughts. |
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. |
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. |
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 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 ============= Now for all of the penalty dynamics. You are sharing a few important scenarios which need to be solved:
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 |
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. |
|
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. |
Imagine this attack scenario for monero: Fill block with min fee tx : fixed cost ~ 0.03 xmr Total cost for a 2x block : 0.7 xmr Block size increases 2x every 50 blocks. That will cost less than 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. |
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. 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. |
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). |
Yup that settles it. |
When the tail-emission era arrives, block reward is calculated as follows:
new_reward = 1.2 * ( x + z ) * ( 2 * x - ( x + z ) ) / ( x ^ 2 )
wherex
is median block size in kb, andz
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 sizez
.Finally the formula for
fee_per_kb
is(1.2 - 1.2 * ( x + z ) *( 2 * x - ( x + z ) ) / ( x ^ 2 )) / z
or quite simplyfee_per_kb = 1.2 z / ( x ^ 2 )
Now we can see the fair
fee_per_kb
depends on two variables:z
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 fairfee_per_kb
is then1.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
of1.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 thefee_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 thefee_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.
The text was updated successfully, but these errors were encountered: