Relevant Links

Approved poll definitions, requirements, and validation parameters

Public attempt at contact #1
Public attempt at contact #2

Critical Information (TL;DR)

Enigma@home will be removed from the whitelist in 3 days (May 31st).

Summary of the Situation

Unfortunately, it seems as though the whitelisted project Enigma@home has essentially stopped allowing sign-ups for new users. They have implemented an invitation code requirement, but there is no posted code anywhere. There has been much discussion on Slack about possible actions that could or should be taken because of this. Here is a brief summary of the main points brought up:

• The recently approved process for whitelisting projects states that the whitelist admin can remove a whitelisted project if they break a requirement for whitelisting.

A whitelist poll is used to add or remove a project from the whitelist. The whitelist is a larger mechanism within the operation of Gridcoin. Each project considered for whitelisting must meet a set of requirements, and several actions must be taken before a poll for adding or removing a project can be considered valid. A project can be removed from the whitelist at the discretion of the whitelist admin if it ever fails to meet a requirement described below.

• The same process states that a project must allow new user registration.

Project Requirements for Whitelist Consideration

• Project Work Availability Score is green
• Number of Zero Credit Days is less than or equal to 7 out of the last 20 days
• The project has a clear description of the work and the work is as described
• The project allows new user registration
• Project complies with the BOINC terms of service
• All crunchers that comply with the terms of service of both BOINC and the project have equal access to work units

• Enigma@home is a legacy project and was not aware of these rules when it was whitelisted (because these rules did not exist).

• Out of respect of the project tenure, an attempt to contact the project should be made before removing it.

• A poll is not required because the project is breaking a cardinal-rule of whitelisting -- this is not a question of project value as was the case with Moo! Wrapper, for example.

• The greylist is not a valid option as the failure of the project has nothing to do with work unit distribution. The greylist is meant to be rules-based/mathematical so it can one day be automated.

• Two public attempts at contacting the project have been made. One on the Enigma@home forums and one on the main BOINC forums. There has been no response from a project admin that clarifies the situation. If there was a response, it was decided that the project would probably be maintained on the network in some form so long as it worked toward a reasonable resolution of the problem.

Actions to be Taken

The first attempt at contact was on May 17th. The second was on May 21st.

Because there has been no response the whitelist admin, informed by the discussions on slack, has decided to remove Enigma@home from the whitelist in 3 days (May 31st).

This is subject to change if the project clarifies the situation to the satisfaction of the whitelist admin, or if the community raises a valid argument for keeping the project on the whitelist.

Moving Forward

The tenure and legacy status of the project were major points during these discussions. Two steps that would help deal with this type of situation in the future have been proposed.

1. During the continued development of outreach and organizational documentation and processes, legacy projects should be contacted and informed of the rules and processes. A position of flexibility should be assumed with these projects. If necessary and where possible, Gridcoin should help these projects develop to fit these rules. Any project that maintains communication with Gridcoin and puts forward a sincere effort at stability and compliance should not be punished.

2. During this process and moving into the future, tenure could be considered as an indicator of intent. This means that a project that has been part of the whitelist for a longer period of time could be given more flexibility than a project that was whitelisted yesterday. This presents a security mechanism that might mitigate the damage done by a project being approved only to immediately break the rules in order to game the system.