The problem of project delisting and proposed solution

in #gridcoin5 years ago (edited)

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:

  1. State clearly when the project will be removed, taking into account grace period mentioned in point 2.
  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).
  3. After the grace period ends, freeze magnitude gain. Do not allow more magnitude to be gained from the project.
  4. 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.



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.

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.

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.

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.

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...

yup, seems like we're one big happy echo chamber = )

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:

  • a member has built-up a certain stable RAC output
  • the RAC output of the project is flat
  • the person is earning 5 GRC (I could have taken any other amount) per day for this project on the day it is delisted

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.

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.

There is no longer PoR. Just PoS claiming the rewards.

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.

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.

Congratulations @artstein! You received a personal award!

Happy Birthday! - You are on the Steem blockchain for 1 year!

Click here to view your Board

Support SteemitBoard's project! Vote for its witness and get one more award!

Congratulations @artstein! You received a personal award!

Happy Birthday! - You are on the Steem blockchain for 2 years!

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!

Coin Marketplace

STEEM 0.20
TRX 0.06
JST 0.026
BTC 28401.68
ETH 1808.89
USDT 1.00
SBD 2.81