Thanks for reviving this thread and the old discussions from last summer. My thoughts on this have evolved considerably since then largely due to gaining a further understanding of the adaptive blocksize limit in Monero and how it impacts fees. In the following post I discussed the response of the adaptive blocksize limit to a spam attack and this is critical in understanding what determines fees in Monero ove the long term.
Rewrite Monero, is not necessary at all but some documentation on how the Cryptonote adaptive blocksize limits actually work is needed, especially given the formula in section 6.2.3 of the Cryptonote Whitepaper is wrong. https://cryptonote.org/whitepaper.pdf. My response will come in time.
I will start by examining the Cryptonote Penalty Function for oversize blocks. This is critical to understand any form of spam attack against a Cryptonote coin. From the Cryptonote whitepaper I cited above the penalty function is:
Penalty = BaseReward (BlkSize / MN - 1)2
The new reward is:
NewReward = BaseReward - Penalty
Where MN is the median of the blocksize over the last N blocks
BlkSize is the size of the current block
BaseReward is the reward as per the emission curve or where applicable the tail emission
NewReward is the actual reward paid to the miner
The Maximum allowed blocksize, BlkSize, is 2MN
The penalty is only applied when BlkSize > (1 + Bmin) MN Where 0 < Bmin < 1 In the Cryptonote whitepaper Bmin = 0.1.
The error in the Cryptonote Whitepaper was to set NewReward = Penalty
For simplicity I will define:
BlkSize = (1+B) MN
BaseReward = Rbase
Penalty (for a given B) = PB
NewReward (for a given B) = RB
The penalty for a given B becomes:
PB = RbaseB2
While the new reward for a given B becomes:
RB = Rbase(1 - B2)
The first derivative of PB with respect to B is
dPB / dB = 2RbaseB
In order to attack the coin by bloating the blocksize the attacker needs to cause at least over 50% of the miners to mine oversize blocks and for an expedient attack close to 100% or the miners to mine oversize blocks. This attack must be a maintained over a sustained period of time and more importantly must be maintained in order to keep the oversized blocks, since once the attack stops the blocks will fall back to their normal size. There are essentially two options here:
1) A 51% attack. I am not going to pursue this for obvious reasons.
2) Induce the existing miners to mine oversize blocks. This is actually the more interesting case; however after cost analysis it becomes effectively a rental version of 1 above. Since the rate of change (first derivative) of PB is proportional to B the most effective option for the attacker is to run the attack with B = 1. The cost of the attack has as a lower bound Rbase but would be higher, and proportional to, Rbase because miners will demand a substantial premium over the base reward to mine the spam blocks due to the increased risk of orphan blocks as the blocksize increases and competition from legitimate users whose cost per KB for transaction fees needed to compete with the attacker will fall as the blocksize increases. The impact on the coin is to stop new coins from being created while the attack is going on. These coins are replaced by the attacker having to buy coins on the open market in order to continue the attack. The impact of this is to further increase the costs to the attacker.
It at this point where we see the critical importance of a tail emission since if Rbase = 0 this attack has zero cost and the tragedy of the commons actually occurs. This is the critical difference between those Cryptonote coins that have a tail emission, and have solved the problem, such as Monero and those that do not, and will in a matter of time become vulnerable, such as Bytecoin.
There are two very distinct scenarios I see for setting fees in Monero.
The first scenario is when the median of the blocksize over the last N blocks, MN < effective median of the blocksize over the last N blocks, M0 = 60000 bytes. This is the current scenario and not the scenario I discuss above, since MN is replaced above by M0 eliminating the penalty for a blocksize increase. The current MN is less than 300 bytes.
The second scenario is where MN > M0 and the penalty applies. In this scenario per KB fees are proportional to the base reward divided by the median of the blocksize over the last N blocks, Rbase/MN. The objective here is to stimulate an efficient market between blocksize scaling and fees. One way to achieve this is to set 5 fee levels corresponding to transaction confirmation priorities. minimal, low, normal, high, very high. The per KB fees are calculated using the known values of the block reward, and, the median of the block size. One places minimal and low below the penalty boundary, normal at the penalty boundary and high and very high above the penalty boundary.
The prior discussion in this thread can in reality only be possibly applied to the first scenario for the minimal fee and the low fee. The rest of the fees would have to be set as above but using M0 rather than MN.
Edit: One important consideration is that there is a 200x increase in transaction volume and possible corresponding increase in price before we trigger the second scenario, so we will have to scale down the fees with no trigger of the penalty. It is here where my original idea as edited and modified above may be a possibility to set the low minimal and low fees.
ArticMine PMed me after I wrote that flaming post, and said he would reply after studying my posts. He has not yet replied. Does that mean I am correct and there is no solution for Monero. I think so.
It is fundamental. Afaics, you'd have to completely rewrite Moaneuro.
It is fundamental. Afaics, you'd have to completely rewrite Moaneuro.
Rewrite Monero, is not necessary at all but some documentation on how the Cryptonote adaptive blocksize limits actually work is needed, especially given the formula in section 6.2.3 of the Cryptonote Whitepaper is wrong. https://cryptonote.org/whitepaper.pdf. My response will come in time.
I will start by examining the Cryptonote Penalty Function for oversize blocks. This is critical to understand any form of spam attack against a Cryptonote coin. From the Cryptonote whitepaper I cited above the penalty function is:
Penalty = BaseReward (BlkSize / MN - 1)2
The new reward is:
NewReward = BaseReward - Penalty
Where MN is the median of the blocksize over the last N blocks
BlkSize is the size of the current block
BaseReward is the reward as per the emission curve or where applicable the tail emission
NewReward is the actual reward paid to the miner
The Maximum allowed blocksize, BlkSize, is 2MN
The penalty is only applied when BlkSize > (1 + Bmin) MN Where 0 < Bmin < 1 In the Cryptonote whitepaper Bmin = 0.1.
The error in the Cryptonote Whitepaper was to set NewReward = Penalty
For simplicity I will define:
BlkSize = (1+B) MN
BaseReward = Rbase
Penalty (for a given B) = PB
NewReward (for a given B) = RB
The penalty for a given B becomes:
PB = RbaseB2
While the new reward for a given B becomes:
RB = Rbase(1 - B2)
The first derivative of PB with respect to B is
dPB / dB = 2RbaseB
In order to attack the coin by bloating the blocksize the attacker needs to cause at least over 50% of the miners to mine oversize blocks and for an expedient attack close to 100% or the miners to mine oversize blocks. This attack must be a maintained over a sustained period of time and more importantly must be maintained in order to keep the oversized blocks, since once the attack stops the blocks will fall back to their normal size. There are essentially two options here:
1) A 51% attack. I am not going to pursue this for obvious reasons.
2) Induce the existing miners to mine oversize blocks. This is actually the more interesting case; however after cost analysis it becomes effectively a rental version of 1 above. Since the rate of change (first derivative) of PB is proportional to B the most effective option for the attacker is to run the attack with B = 1. The cost of the attack has as a lower bound Rbase but would be higher, and proportional to, Rbase because miners will demand a substantial premium over the base reward to mine the spam blocks due to the increased risk of orphan blocks as the blocksize increases and competition from legitimate users whose cost per KB for transaction fees needed to compete with the attacker will fall as the blocksize increases. The impact on the coin is to stop new coins from being created while the attack is going on. These coins are replaced by the attacker having to buy coins on the open market in order to continue the attack. The impact of this is to further increase the costs to the attacker.
It at this point where we see the critical importance of a tail emission since if Rbase = 0 this attack has zero cost and the tragedy of the commons actually occurs. This is the critical difference between those Cryptonote coins that have a tail emission, and have solved the problem, such as Monero and those that do not, and will in a matter of time become vulnerable, such as Bytecoin.
There are two very distinct scenarios I see for setting fees in Monero.
The first scenario is when the median of the blocksize over the last N blocks, MN < effective median of the blocksize over the last N blocks, M0 = 60000 bytes. This is the current scenario and not the scenario I discuss above, since MN is replaced above by M0 eliminating the penalty for a blocksize increase. The current MN is less than 300 bytes.
The second scenario is where MN > M0 and the penalty applies. In this scenario per KB fees are proportional to the base reward divided by the median of the blocksize over the last N blocks, Rbase/MN. The objective here is to stimulate an efficient market between blocksize scaling and fees. One way to achieve this is to set 5 fee levels corresponding to transaction confirmation priorities. minimal, low, normal, high, very high. The per KB fees are calculated using the known values of the block reward, and, the median of the block size. One places minimal and low below the penalty boundary, normal at the penalty boundary and high and very high above the penalty boundary.
The prior discussion in this thread can in reality only be possibly applied to the first scenario for the minimal fee and the low fee. The rest of the fees would have to be set as above but using M0 rather than MN.
Edit: One important consideration is that there is a 200x increase in transaction volume and possible corresponding increase in price before we trigger the second scenario, so we will have to scale down the fees with no trigger of the penalty. It is here where my original idea as edited and modified above may be a possibility to set the low minimal and low fees.