Gridcoin 4.0-2018 General Roadmap Poll - Determining Magnitude
Gridcoin 4.0-2018 General Roadmap Poll - Determining Magnitude
This is the description and thread for the Gridcoin 4.0-2018 General Roadmap Poll pertaining to how a user’s magnitude is calculated. You can find the Cryptocurrency Talk thread, which contains information on all polls, here. Any questions asked on this thread should relate only to this poll. Any questions on the Cryptocurrency Talk thread that are related to this poll will be relayed here and vice versa. Please, do not be afraid to ask questions. We want to make sure that everyone understands what they are voting on.
You can find the poll on Gridcoinstats here.
The poll was made by @tomasbrod with address: SFhy5MRyNqVcC2pCtEYeMSULe6wA5SPYMk.
Magnitude is the Gridcoin variable which determines a user’s Earned Research Rewards. Gridcoin currently calculates a user’s magnitude through the BOINC variable Recent Average Credit, or RAC. Total Credit Delta, or TCD, is the proposed replacement for calculating user magnitude. Instead of using RAC, magnitude would be calculated by determining the difference in a user’s credits earned on a specific project between superblocks. As with anything, there are benefits and drawbacks to a TCD system.
There are many aspects to a magnitude determination structure. Below are those we have compiled and how they manifest in each structure. It is up to the community to discuss the pros and cons of each.
Charge Time
RAC - A user must charge their RAC for an extended period whenever they start a new project or rejoin a project after an extended absence.
TCD - After the initial collection of a user’s stats, there is no charge time in TCD.
Deflation Time
RAC - When a user leaves a project, they maintain a RAC for the time required for their average to reach 0.
TCD - There is no deflation time in TCD.
BOINC Project Runs Out of WU or Otherwise Fails
RAC - So long as a project is whitelisted and a user has RAC on that project, that user will be rewarded with GRC, regardless of active work done.
TCD - A user is rewarded with GRC only if there is a difference between that user’s completed credits between superblocks.
Note - While TCD presents an improvement over RAC with regards to a project running out of work units, it is intend to and works best with a steady stream of work units.
Earnings Estimation
RAC - It is difficult to accurately estimate RAC -> Magnitude -> GRC for a user.
TCD - It is relatively simple to accurately estimate TCD -> Magnitude -> GRC for a user.
Loss of Service
RAC - When a user loses service, they continue to be rewarded with GRC based on their RAC and RAC decay time.
TCD - When a user loses service, they are not rewarded with GRC until service is restored.
Cycle to Reward Relationship
RAC - Due to using an average, the connection between RAC and actual cycles contributed to BOINC projects is indirect. The connection is rooted in the individual credit system of each project.
TCD - The relationship between TCD and actual cycles contributed to BOINC projects is more direct than RAC. The connection is rooted in the individual credit system of each project.
"Do you think Total Credit Delta is something that should be implemented in 2018"
-Yes
-No
-No, but we should not use RAC either.
-Need more information
-Abstain
Having thought long and hard about this, TCD seems the way to go. Did anyone take the time to draw up a list of CONS for this proposal?
Cons to the proposal might include loss of service (above), and running out of WU's on a project (also above).
But beyond that, my imagination doesn't venture into the downsides too much on this one.
EDIT: I do note from the Preliminary that is linked that TCD will also remove the "smoothing" effect of RAC. But IMHO volatility in payout is really a response to volatility of work. Consistent work should consistently payout. Right?
In response to your question: Right. I agree.
I honestly do not think there are many cons that do not already have solutions or potential solutions.
And don't forget you can always change your vote if you end up changing your mind! There may very well be more discussions that stumble on some critical flaw of the proposal, but who knows.
More technical and popular information regarding this topic can be found in the Original read-map article and a chain of progress reports
I see one more benefit: TCD is easier to understand for a new user. IMO
During the months of discussion, TCD was a very popular proposal. Unless some strong, viable criticism is raised, I will be voting in favor of implementing Total Credit Delta.
I'm in support of TCD as long as we only account for the difference in total_credit AFTER the beacon has been registered, otherwise we incentivize the hacking of large total_credit BOINC accounts.
I assure you that no retro activity will be permitted.
Say I complete a GFN22 workunit at Primegrid (very large with a lot of credit). Then my TCD will be very high in the next superblock. If I don't manage to stake in that superblock, my TCD will plummet, especially if I work on another GFN22. Will rewards from TCD carry over in some way to the next superblock if I don't stake? It's the one thing I like about RAC.
Total Credit Delta is only used for the calculation of how much the network owes you. You are then rewarded the sum total of all the GRC for everything you've researched (up to a six month period) in one stake.
So in your example, the network will see that you have a high TCD after completing your GFN22 workunit and it will add the appropriate amount of GRC to the amount your will be rewarded in your next successful stake. Then your TCD plummets and it adds much less to the already existing pending reward. Finally you stake and you receive it all.
TL;DR: Yes, your reward carries over even if you don't stake. You will still be paid fairly.
I remember there being a discussion somewhere about the risk of someone exploiting TCD by "bunkering", i.e. downloading a bunch of project work units at once, processing them, and waiting to upload the results until a drop in workunit supply from the project servers. If the workunit supply is significantly depleted (which definitely DOES happen occasionally in practice) then this person could dominate the project magnitude and get huge research rewards.
RAC is resistant to this exploit since it is a moving average which smooths out a researcher's output [credits/unit time] over the timescale of a couple of weeks. On the other hand, to protect TCD from the exploit we really do need stricter standards for projects (i.e. minimum workunit supply requirements) and a mechanism for rapidly sending projects to a greylist if they drop below this requirement. It seems to me that TCD should only be considered in combination with this mechanism.
There's some more in depth technical analysis which can be done in connection with this proposal. What I have in mind is quantifying any possible exploits/weaknesses in each proposed mechanism by parametrizing with respect to a finite number of variables, and maximizing research rewards with respect to those variables. I want to work on this if I have time (never a guarantee given my current job, but we'll see!).