Please consider removing the magnitude unit

[a123b]

When I saw issue #768, I realised that it could possibly allow to drop one of my top "annoyances"
in Gridcoin: the magnitude unit.
This motivated me to write this "proposal".
First, I'd like to mention that I don't even think I'm really qualified enough to talk about such important consensus rules, so please look at this more like a general idea than a definite proposal. So even in case there are some flaws in here, I hope it will start some discussion about this among the developers that could lead to much more fairness in the upcoming new reward mechanism than in the current one.

Proposed changes

• Instead of using only the latest superblock and the one that was used for the last PoR stake,
  calculate the reward based on all superblocks in between.
  This has already been proposed as Base PoR rewards on superblock windows #768.
• Use blocks as time unit instead of actual unix timestamps, with a PoR emission target of
  28800 GRC per 960 blocks (as defined by the CBR poll result)
• Remove the magnitude unit, as the two points above have just made it obsolete.
  Total GRC rewarded for research per 960 blocks (~daily) per magnitude will now be constant:

NEURALNETWORKMULTIPLIER = 115000
POR_EMISSION_TARGET = 28800
GRC_PER_MAG_PER_960_BLOCKS = NEURALNETWORKMULTIPLIER / POR_EMISSION_TARGET

• (Maybe raise the neural network multiplier to 115200 so that this constant will be an exact 0.25?)
• (Alternatively, redefine magnitude as "GRC you get per 960 blocks" and use the emission target itself as neural network multiplier?)

Why?

As it is right now, you can gain a slight advantage by switching to investor mode when the mag unit is low and only start staking with your CPID when it gets higher (assuming your magnitude is fairly constant). If you have a decent balance (enough to stake daily, for example), this is actually very much viable. It would even be possible to automate this by changing the miner code to only stake with CPID if the mag unit is above a defined limit.
The problem is that this creates an unfair disadvantage for users who don't have a balance high enough to somewhat have control over when to do DPoR stakes. Some might stake so rarely that they have to do every stake with CPID if they don't want to risk losing rewards.

If #768 gets implemented in a way that uses block distance instead of timestamps, there would be absolutely no reason for the mag unit to exist anymore. Its sole purpose was to balance out fluctuations in the daily PoR emission, which are gone anyway with these changes. If there's a day paying out less GRC than the target, the difference is guaranteed to be owed and claimed on some other day in the future. Assuming MRC will get implemented, it's entirely up to the cruncher whether it will get claimed or will expire/get burned.

"But won't the emission get too high if the mag unit is raised and fixed to 0.25?"

No. The reason why the mag unit fluctuates between 0.175 and 0.225 right now is that a) some users are probably using the flaws in the current reward calculation to their advantage (see #768) and b) the difficulty has been too high lately, so instead of the targeted 960, only about 880 blocks are being generated per day. As the current reward calculation uses timestamps instead of block distance, this has to be balanced out by lowering the mag unit currently.
a) is fixed by the first point of the proposal, b) by the second one.

"Solo crunchers missing the ~6 months lookback window will lower the emission"

This will be very unlikely to happen once MRC is implemented. The only way this could happen will then be that the cruncher forgets about his pending rewards and doesn't open the wallet in time.
Just consider the burnt coins as a donation to all GRC holders.

[jamescowens]

#768 is an excellent idea, and in fact, much of the optimization (the new superblock class), upgrade to leveldb 1.20, and other optimizations are to enable the use of the chain of superblocks between the miner's last stake and current one to calculate the rewards rather than the two, or three point average that is done curently. (The three point average for a span between stakes of more than 20*960 blocks is particularly problematic, plain idiotic, and originally incorrectly coded even within its own concept... which was the root of a lot of the forking prior to 4.0.1.0.)

On the 14 day feedback filter that adjusts the value of the mag unit... we have had a number of discussions among the core devs about throwing this out and just using a fixed mag unit. (Essentially as you said, the mag unit simply becomes a fixed ratio relating the desired emission per 960 block span to the total network magnitude).

I think you are not necessarily completely considering what causes the "jitter" in the mag unit.

The first reason is that the mag unit unnecessarily was "snapped to grid" by Rob, and those grid points are not equal to 5/9 * (50500) / 115000, which is the equilibrium value of the filter target emission as a function of maximum emission divided by the network magnitude:

5/9 * (50500) / 115000 = 0.24396 not equal to 0.225 or 0.25.

The second reason for the jitter is the following: consider the quadrant diagram:

High Balance Low Mag	High Balance High Mag
Low Balance Low Mag	Low Balance High Mag

The low balance, low mag folks really don't move the needle that much period. The high balance, high mag folks stake multiple times per day, or at least once per day, so they are contributing "evenly" to the daily emission. The high balance, but low magnitude folks are irrelevant for this discussion. Finally, you have the low balance, high magnitude corner case. This is the problem quadrant. Someone that has a relatively high magnitude but quite low balance can disturb the daily payout when they finally stake.

And then you could move the needle slightly by playing games as you described.

Quite frankly my position is that the filter is more trouble than it is worth and we should adopt a constant GRC emission to network mag ratio. I think @cyrossignol feels the same way. The payout by definition over reasonable period of days will be at the emission rate, because the fluctuations will cancel out. It doesn't matter that the payout on one day is slightly higher than another.

On the subject of timestamps versus block distance...

First.... I am not sure why we are seeing less than 960 blocks per day as of late. The target window (a la difficulty because they are inversely related) is adjusted every block to try and maintain spacing at 90 seconds, which is 960 blocks per day. The only way the network can be maintaining less than that is some "drag force" delaying the production of blocks compared to the calculation of the target window. We are still seeing some short term forks (5 - 6 blocks long), which are normal, but they also destroy staked blocks in the fork when they are reorganized out, so this may be contributing to lower than expected blocks per day. We need to look into this and it may result in a change in the target adjustment calculation.

Second.... I like the idea of computing payouts (the SB window chain, and then the distance from the last SB to the actual stake) in chain distance rather than time. It would simplify things dramatically.

I think it also exposes us to a different set of possible attacks to try and affect the block spacing to distort the second layer (research) rewards. We need to do some thinking about that.

Our goal is to get as many of these changes into Fern as possible... hence the Herculean task Fern is....

[cyrossignol]

@a123b Thanks for bringing this up and for your detailed analysis. I think you understand these problems very well, and I agree with everything that you and @jamescowens discussed here and in #1579. We've been planning to address these issues for some time now. In fact, I'm already neck deep into refactoring the core accrual system so we can extend it beyond the problematic, time-based research age calculations and derive rewards with precision from superblock windows as described in #768.

The above builds on months of clean-up work and improvements to bring the legacy code to a level of sanity and performance that allows us to explore these ideas. There's some stickiness around the scalability of scanning back through months of superblocks for each reward block. Superblocks are large data structures, and will grow larger as more users participate, so we certainly cannot store all that data in memory, and reading dozens of MB from disk in the worst case to validate each reward block will dramatically slow down sync speed. I'm working on a caching and indexing strategy to make this approach more feasible.

[jamescowens]

@cyrossignol have agreed to retain the magnitude unit, but instead make it a fixed ratio that relates the network-wide magnitude to the desired emission rate per 960 blocks. We are going to set it at 0.25 which gives 28750 GRC per 960 blocks, very close to the intended equilibrium value today. The magnitude unit is, via this approach, redefined to use blocks as the basis rather than time. We are going to use block spans and not time for all research rewards payments in block v11 (Fern) forwards.

[jamescowens]

The reason for the retention of the magnitude unit, is that we want to retain the decoupling of the choice of network wide magnitude value from the block spacing. In other words, if we want to change the block spacing in the future, we need to have the magnitude unit, to be able to change that and adjust the relationship between network-wide magnitude and the block spacing to maintain a constant actual payout per effective day, without having to change the network-wide magnitude value.