Hello fellow researchers,
I do not normally write articles, but the recent delist of Moo! Wrapper and the repercussions motivated me to touch this sensitive subject. Please note that this problem will be most likely alleviated when the project greylisting and/or manual claims ideas come online, but that may take a lot of time and by then, even more damage to the system could be done. The purpose of this article is to point out the problem, propose a solution and justify it.
After the recent Moo! Wrapper delist there was an uproar that you automatically lose magnitude (as well as already owed and/or future GRC?) right after the subsequent superblock. In other words, no matter how much you crunched a project, you lose everything you have gained the moment it is delisted if you did not stake a block that one specific day (between poll results and superblock). This issue did not touch me personally (I did not crunch on Moo! Wrapper), so I can not speak for myself. Nevertheless, I am asking this question: is that true?
Because if it is, then I must remind you of one universally agreed rule: lex retro non agit, known as Intertemporal Law - the law does not work backwards. How it applies to cryptocurrencies? Naturally, any major change to the system can not affect the users' past. Maybe some of you remember the infamous DAO hack, Ethereum rollback and subsequent split of the community. As we know, it ended with hard-fork and two cryptocurrencies being formed: Ethereum ETH and Ethereum Classic ETC. All of this happened because a large part of the community believed in the lex retro non agit rule, which was also supposed to form the grounds of cryptocurrencies (all transactions are final).
Naturally, the solution to this problem that I decided to put forward is as follows:
After project delist is voted:
- State clearly when the project will be removed, taking into account grace period mentioned in point 2.
- Provide grace period of one week (up to debate) - so that people have time to switch to different projects and finish their current tasks (which sometimes take a lot of time, even a few days for those extra long tasks).
- After the grace period ends, freeze magnitude gain. Do not allow more magnitude to be gained from the project.
- Let magnitude decay naturally, while providing normal payouts to the researchers.
Point 4 is obviously the core of the solution. I believe that rewarding the researchers for the work done even after the project is delisted is completely in line with yet another universal economic rule that all work deserves to be rewarded.
Sources:
https://www.reddit.com/r/gridcoin/comments/7wigs0/moo_whitelist_poll_complete_remove/
https://en.wikipedia.org/wiki/Intertemporal_law
https://www.coindesk.com/understanding-dao-hack-journalists/
Thanks for the write-up!
For further reading, take a look at the two proposed whitelist procedures (including the greylist) that address some of these issues. One is being voted on right now!
Adding a Project and the Greylist - Voting going on now!
Delisting a project - Work in Progress Proposal
Otherwise, I think you have 2 good points that havn't been discussed at length -- the grace period of a project for when it is greylisted, along with possible continued payout during magnitude decay.
I will post these ideas on the GitHub unless you would like to.
Personally, I don't entirely agree with rewarding magnitude decay for a removed project. The goal is to work toward rewarding actual work done. Rewarding decay is not this.
In addition, I can imagine someone noticing a project will be dewhitelisted in 2-3 weeks, moving their hardware to that project, charging their mag on that project as other people leave the project, and reaping the benefits of a low mag distribution pool as their mag reduces to 0 while their hardware now crunches away on another project.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
One could argue that the rewards from decaying mag are exactly equal to the rewards "lost" during the initial buildup of mag, see the plot in @parejan 's comment on this post. In that sense it would be natural to continue rewarding decaying mag. This is an ugly solution though. I hope many of these problems will be swept away by a successful implementation of the roadmap proposals.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
I was waiting for this response! = )
In my opinion, the possibility to exploit payout for power-down (due to the likelihood of a lower pool of users working on the project) outweighs the benefit to paying mag lost during charging.
In general, I agree and also hope the proposed roadmap developments will look to solve these issues.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
I think there would be some ways to further develop this but as we only have limited resources available, it would be more beneficial to use them for new developments in the proposed roadmap instead of using these resources for temporary fix. I think we have the same position here...
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
yup, seems like we're one big happy echo chamber = )
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
nice post
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thanks for the interesting article @artstein. To support your argument the RAC build and decline is gradual. To illustrate this, I have added a chart with RAC decline as percentage of the point when a project would be delisted.
Assuming the following:
Using the graph above, you can calculate that a person would theoretically lose around 45 GRC as none realised contribution building up his RAC output. This basically means with delisting a project s/he has crunched around 9 days on this project for the benefit of science only (based on the assumptions above, which I wouldn’t consider exceptional).
Obviously this is not rewarding for decay. The amount paid in the decay period is actually the work performed but not rewarded while building up the initial RAC output to maximum level (which only happens after +/- 30 days). If you look at the chart below, the blue area on the left of the green line is identical to the blue area on the right of the green line.
Due to the complexity of the RAC build-up/run-down mechanism, I would instead of developing the process above, explore and implement TCD to address the issues.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thank you for your comment. I agree, integrating the decaying function you presented will give us insight into the value of the missed GRC, but it does not include the GRC missed through unclaimed PoR prior to the delist. I am, however, unsure if this is the case; it could be that the PoR is saved and simply added to the next stake reward, regardless of the project status. Some input from a Moo! cruncher affected by this would be welcome.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
There is no longer PoR. Just PoS claiming the rewards.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
here i'm
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thanks for the post! I definitely agree with the basic premise.
On the other hand, the problem may end up being solved simply as a side-effect of the Gridcoin 4.0 Roadmap proposals, particularly TCD and manual claim rewards. These two mechanisms would give users much greater control over their magnitude and payouts. The current greylist/whitelist proposals are also relevant. Perhaps one could do an analysis to see whether these roadmap + greylist/whitelist proposals are sufficient by themselves to eliminate the problem.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Please consider that for some projects the reason for de-listing is indeed to address the unfair MAG allocation they cause. (e.g the recent poll for de-listing SourceFinder).
Hence the proposed "solution" seems to be very case specific. Implementing case specific solutions would make the protocol overly complex and difficult to maintain.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Congratulations @artstein! You received a personal award!
Happy Birthday! - You are on the Steem blockchain for 1 year!
Click here to view your Board
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Congratulations @artstein! You received a personal award!
You can view your badges on your Steem Board and compare to others on the Steem Ranking
Vote for @Steemitboard as a witness to get one more award and increased upvotes!
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit