Why the Sourcefinder Vote Still Matters
You may have been celebrating the implementation of the greylisting process over the past week.
If you missed the party, know that the greylist will greatly improve our ability to manage the whitelist without the need for time consuming and controversial polls. It is based on clearly defined parameters that can be found in detail here. Essentially, if a project runs out of work units for a period of time, it is greylisted until it demonstrates that it has work for the Gridcoin network to crunch. This will reduce the number of GRC distributed to idle crunchers.
As with any set of parameters, there are outliers that pass through the gates, but do not meet the intention of the court-yard.
Sourcefinder is one such project.
If Sourcefinder is not delisted, it will not be greylisted.
The way the project releases its work units ensures that the greylist protocol does not stop it at the gates. This is not intentional on their part or malicious in any way. It simply is what is.
As we continue to build on the greylist protocol (it is currently v1.0), we will undoubtedly attempt to learn from these outlier scenarios and implement parameters that intend to tighten security. Until then, we will need to remain vigilant and use polls.
In the words of @guk
Sourcefinder keeps producing a trickle of credit so they don't have any zero credit days. They also produce so little work that there is no big drop in credit being generated to detect and trigger on.
As stated before we need to develop a way of measuring how much compute a project needs and what a minimum to support Gridcoin. We can't do this at the moment so still require Listing & De-Listing polls to weed out the oddball projects.
The Greylist will be able manage the vast majority of projects however and gives us a basis to expand into an improved V2 later.
If you vote no on the poll to delist Sourcefinder with the assumption that it will be greylisted when it is not delisted, you may want to reconsider your vote.
Whether you vote yes or no on the poll, VOTE.
The poll ends February 28th.
You can follow the greylist here.
Sad facts. If they can't provide enough work for "everybody", then they shouldn't be on the whitelist unfortunately. :(
And I can vouch for the fact that the way they release workunits is in no way malicious. Gridcoin has a fairly good rapport with the administrator of the project, Sam Foster, and he has been forthright in all communications. It is even his own suggestion to remove Sourcefinder if it's causing us troubles.
This really is an interesting test case, I never expected that a project would "fly under the radar" in this way.
If Source Finder was not already white-listed it may not be eligible for white-list consideration based on the requirement:
This raises two questions for me:
Source Finder would have been grey-listed under the new policy when its Work Availability Score (WAS) became RED on previous occasions but the fact that it has had a consistently low level of work for an extended period gives it a green WAS right now. The other grey-list trigger is Zero Credit Days (ZCD) ≤ 7 in 20 which will adequately trap projects that are able to produce an ample supply of work periodically or projects with a temporary shortage of work but due to the latency in processing work units won't trap projects that are consistently under supplying work.
It seems a project that is grey-listed for low WAS could become automatically white-listed under the current policy if it at least provides a consistent level of work even if it is a very small amount. In this case I would expect a poll for de-listing created during the grey-list period but Ideally such a project shouldn't be automatically restored to white-list status.
If it is possible to capture the number of days a project has Zero Work Available it could be a useful metric to filter projects that are under supplying work.
As I see it, the most important issue for the Gridcoin network is not how much work a project can produce but whether all of the Gridcoin miners contributing to a project have an equal chance at receiving enough work to maintain a fair payment distribution.
I am celebrating the new white-list management procedure, it is a positive step for Gridcoin and in most cases will serve it's purpose very well. Source Finder may have inadvertently caused some frustration with the timing of events but it has provided some valuable insight into potential flaws at an early stage.
Yes I am late to the party, but as I am not invited to GRIDCOIN Slack, I am not able to read the discussion over there, but in my opinion the rules are flowed!
“A project will be automatically Greylisted if ANY ONE of the following requirements are met:
• Projects Work Availability Score (WAS) is Red
• Number of Zero Credit Days (ZCD) > 7 in 20”
Most of the projects have a double check mechanism implemented to check each work unit, with fairly long waiting periods to return a work unit and if the results double check is negative or the work unit is not returned in time or is broken, the work unit is resent to a third computer until the results is conclusive.
So if a project is greylisted or blacklisted for not have WU available, but within the waiting period of the wingman’s result is greater 7 dias, GRIDCOIN will not pay the corresponding GRC for completed work.
this is an the edge effect, normally you crunch a project continuously for months. the graylist is addressing much larger discrepancies, what you bring up is 3th/4th order effects. Imagine you are designing a mosquito sprayer to stop malaria spreading, and somebody brings up the issue of the compressor noise.
If a project runs out of work it will still be awarding credit as long as there are work units being processed, this includes wingman tasks and work unit caches, It will take a long time for the daily credit to reach zero. A project that has run out of work will probably get a low Work Availability Score before it reaches Zero Credit.