Thoughts on Changing the Way Project Magnitude is Calculated

[ghost]

Here's an excerpt from a conversation we had on IRC about the decay of RAC being different on each project.

<BullShark> is it just me, or do some project RACS decay faster than others?
<jamezz> its not you
<jamezz> like dude i aint done collatz in months
<jamezz> aint done GPUgrid in 4 months
<pepperooo> nfs decays fast, gpugrid decays faster :(
<BullShark> Shouldn't we be calculating our own RAC then to make it fairer
<jamezz> its because every project has a different credit system

Would it be possible to change the way RAC is calculated so that we do the calculation in the NN code when we calculate the project magnitudes. We could do this by calculating the difference of the users total credit when they first registered their CPID in the NN to what they have now.

Some potential issue

• They would not be rewarded for work that was done before they registered their CPID in the blockchain.
• Would deleting beacons cause mag to drop to 0?

Is it fair the way it is now? Or should we look at changing it?

[grctest]

I like the current method of calculating magnitude on an individual project basis, proportional computation rewards (your_rac/team_rac).

If individual projects seem to have issues with their credit mechanisms it would be a good idea to contact their development team regarding your concerns.

Reason I think we should stick to using the project's RAC is that its a simple value that they already have, making it more abstract could be an additional hurdle for new users to understand how much they're capable of earning.

Aiding in development of the 4th gen credit mechanism could help prevent projects having to reinvent the wheel: https://boinc.berkeley.edu/dev/forum_thread.php?id=10953

[iFoggz]

I agree about keeping it the same and each project admin tinkers with there own projects. A 4th credit system could be great however we may have similar situation as projects don't all just update to new system.

[tomasbrod]

I thing we should calculate the magnitude ourself. Calculate magnitude difference in total credits since last superblock. Why? When projects go offline or project stats not updating, the mag calculation ceases tho be fair.

[iFoggz]

so get the neural network to do all the calculations then? if projects are down that information would not be accurate either as boinc gathers that information from the projects and not in client. also would have to add code so the wallets would even keep an updated rac amount as it doesn't. and even then it can be manipulated as well still.

[ghost]

Yeah, it doesn't seem fair that users can be rewarded for doing nothing just because they picked a project that takes ages for RAC to decay.

I agree with @tomasbrod if it's possible we should calculate mags ourselves and make it maybe make it decay down to 0 after 30 days. Then it does not matter which project you choose they will all be the same.

I don't think magnitude is hard to understand. We already use magnitude. It's actually harder to learn RAC and Magnitude. Especially if people are new to BOINC.

[iFoggz]

@3ullShark

I hear you but I do have concerns.

• How are you proposing exactly that the magnitude be calculated?
• Who exactly is ourselves? the neural network? the person who owns the cpid?
• Where is the RAC or MAG from the stats actually going to come from and where are you going to actually get these stats?
  ** We can't use the boinc client for the stats as it wouldn't be accurate either when project is down.
  ** Also if we did we would be adding more cpu usage as the wallet would have to keep either in sync or updated from the client_state.xml.
  ** At boot up the wallet checks client_state.xml for cpid information and if rac is over 100, etc but is not regularly updated least ive never seen as my list cpids been the same over days.
• If the neural network is going to calculate all this where is it going to gather any kind of RAC or MAG information if we not using projects stats that are from the projects themselves? Remember the stats are not always perfect but they come from the project not a gridcoiner.
  ** Surely we can't allow a local client to calculate there own RAC or MAG as it can be manipulated unlike the neural network comes onto a consensus between the NN clients.
  ** Where will there be consensus on whether or not that information for RAC or MAG is correct?
• If the neural network is going to do all these calculations it would be a over work of all the code as the network would have to also essentially come to a consensus which is like voting for popular stats.

Also there is a reason its 115000 * ((Your RAC / Team RAC) / WhitelistProject count)

Whitelist project count makes an even amount of magnitude spread across all projects meaning generally there is so many coins per day per project thou ur not neccessarily paid that day for that project. One project should not be favoured more then another and there not. Also Its not the NN fault that a project server is down and thus a greylist would help here however if the project is down then the NN should not allow rewarding for them during that time frame as there is no stats to fairly reward users to begin with so using the 1 sb stats before hand would be a disaster as well. yes it affects your mag when the projects are down and NN can't get that information.

Your RAC / Team RAC is because your in competition for the magnitude in each project. You bring more hardware to the table then your spending more money on hardware and electricity or if you make wise project choices for your hardware as well as other factors. It is a competition for the MAG and coins.

115000 Neural Multiplier keeps the Network Magnitude below 115000 Magnitude and that along with mag unit keeps the network steady in coin production for DPoR.

I'm greatly concerned about the what "ifs" in this situation. I understand people want to work towards change and thats one thing but you talking about redesigning gridcoin completely. Also there would have to be a consensus vote on this of course once you've laid out all the outcomes to this and complete direction to this.

I can't even begin to imagine the biggest hardest fork of gridcoin to ever happen. This kind sounding like a direction of other crypto coins leaning toward splitting into two different coins.

Not throwing your ideas under the bus at all but there is lack of direction and information to support the idea. Brainstorming is one thing but showing everything in complete documentation is more realistic then "what ifs"
To be honest its almost like a whole new coin being developed here and gridcoin is the base coin its derived from.