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

proposal: BOINC Reward and Magnitude Calculation #4

Open
tomasbrod opened this issue Oct 11, 2017 · 1 comment
Open

proposal: BOINC Reward and Magnitude Calculation #4

tomasbrod opened this issue Oct 11, 2017 · 1 comment

Comments

@tomasbrod
Copy link
Owner

tomasbrod commented Oct 11, 2017

Reward calculation

Currently research reward is calculated inaccurately and changes depending on number of
days/blocks since the previous reward. If less than 10 blocks passed, the reward is zero and is
not counted as a reward at all.
Or if more than 6 months (6*30*1000 blks) passed or no previous reward was found, Newbie boost is used,
which I won't be covering here.

If less than 20 days (20000 blocks) passed, the reward is:

 AccrualAge * MagnitudeUnit * (PreviousMagnitude + CurrentMagnitude) / 2 coins.

If more than 20 days but less than 6 months passed, then the reward is:

 AccrualAge * MagnitudeUnit * (PreviousMagnitude + CurrentMagnitude + LifetimeAvgMagnitude) / 3 coins.

If more than 6 months, things get complicated and you will get much less reward.
Most of the time only sightly above 1 GRC.

Where AccrualAge is number of days since last reward, PreviousMagnitude is magnitude at the
time of last reward, LifetimeAvgMagnitude is supposed to be average magnitude of the
researcher over some unknown time (6 month? all time?).

As we can see the calculation is not accurate at all, especially for less often staking
miners with low balance. Temporary increase or dips in magnitude are not taken into
account. If a NN glitch occurs and individual magnitude goes well up (or down) and the user
has the luck to stake, he is rewarded with too high (or low) amount.

And we can also see that the Savings account was a rumor. No owed reward is saved.
RSA Fulfilment percent is not included in the calculation. Once a reward is staked, all
past under/over payments are forgotten.

Magnitude calculation

Researchers magnitude is calculated in the Neural Network
(which is not a neural network, just a silly name).
Individual magnitude is average of all his magnitude in all projects.
Magnitude in a project is current Recent Average Credit of individual
divided by RAC of team Gridcoin in that project.

IndPrjMag := (IndPrjRAC / TeamPrjRAC) / ProjectCount * Const
Magnitude := Sum[i]( IndPrjMag[i] )

Which is equivalent to:

IndPrjMag2 := (IndPrjRAC / TeamPrjRAC) * Const
Magnitude := Avg[i]( IndPrjMag2[i] )

Usage of RAC in mag calculation may cause issues because:
Different projects decay rac differently.
When a project stats are not updated the rac stays same, thus magnitude is
calculated wrong and too much reward is distributed. When a project goes
offline, magnitude falls to zero.

Magnitude proposal

I propose to replace recent average credit with difference in total credit.
And add a check for zero or negative team credit difference.
This way all contribution is preserved.
The superblock format must be changed for this to work.

CreditDif = TotalCredit - prev.TotalCredit
TeamPrjDifRA = x day Average of Project credit difference
IndPrjMag := (IndPrjDif / TeamPrjDifRA) * Const
Mag := Avg[i]( IndPrjMag[i] )

This will become more clear when a working prototype is created.

(TomasBrod's NN participant proposal moved to [[DEV Neural Network]])
(TheCharlatan's Beacon proposal moved to [[DEV CPID Ownership]])
(TomasBrod's Beacon Minting proposal moved to [[DPoR Payments]])

Reward proposal

Therefore I propose to calculate reward from weighted average of magnitudes in
superblock since previous reward. More detailed in the following formula:

reward := Sum[i](
  superblock[i].mag[cpid] * min(0, 
    min(superblock[i+1].time, this.time) -
    superblock[i].time
  )
) * MagnitudeUnit;

where prev is previous reward transaction,
i goes from the superblock that precedes prev to the current superblock,
time of not-yet-staked superblock is assumebd to be in infinity.

@tomasbrod
Copy link
Owner Author

Added: As a nice alternative to Greylisting, solution to unfair earnings when project runs out of work, but some users have wus left. Instead of using daily project credit delta in the equation, smooth the value with a fast-builup slow-decay filter.

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

1 participant