Why Gridcoin Whitelisting Must Go
Ahoy! Incoming Wall o' Text!
First, definitions.
Gridcoin: Gridcoin is a cryptocurrency that "reward[s] volunteer distributed computing" on top of a proof-of-stake blockchain.
BOINC: The Berkeley Open Infrastructure for Network Computing. Basically, this is a free, open-source SDK (Software Development Kit) which provides the infrastructure for deploying and tracking progress on distributed computing projects. Anybody can use it to make their own platform. Contrary to popular belief, this is not restricted to scientific projects. BOINC explicitly supports business use cases. [Note: the linked page is currently down but is linked as "Companies" from the BOINC main page.]
Whitelisting: In order to reward volunteer distributed computing, the Gridcoin network maintains a list of URLs of BOINC projects for which distributed computing contributions will be honored. Currently, inclusion onto this list is facilitated by decentralized on-chain voting (this one, for example) and manual whitelisting by a trusted administrator following vote outcomes. Removal follows the same process.
Why whitelisting?
Presumably, the purpose of whitelisting is to avoid including projects in the network which convey unfair advantages to participants or are in some form or fashion "malicious." This means that if a project publishes fake or altered stats, or consistently fails to provide enough work to give all Gridcoin participants a chance to earn GRC for completing its work units, or in some other way does not appeal to the voting participants, it will not be whitelisted or will be removed from the list.
So why is it bad?
Whitelisting has been a perfectly acceptable way to get Gridcoin off the ground. It avoids the need for a potentially complex engine to identify and automate the inclusion of valid projects, and makes it fairly easy to remove projects that don't meet the community standards for inclusion into the reward pool.
Going forward, it needs to go.
1. Whitelisting is political.
This is the most important objection. By definition, any process that requires a vote for inclusion is subject to the subjective whims and tastes of the participants. For example, climate change and applied genetics are often controversial areas of science, subject to bitter arguments on national stages. We still find people with religious qualms about some types of earth sciences. Cold fusion is still up for debate. Once, it was heresy to support heliocentrism. And Gridcoin itself has a strong core set of participants who believe that no commercial projects should be supported by the network despite no technical reason for their exclusion.
Rather than arguing about where to draw the line -- do we allow climate projects? do we allow projects not sponsored directly by major universities? do we exclude projects funded by grant money tied back to commercial entities? do we accept commercial projects, and if so, which ones? -- I'd argue that we'd be much better served simply accepting any project that can provide sufficient work units and has not been identified as malicious in some form or fashion. Research participants can decide whether to back these projects with their crunching choices, and if the projects are malicious they can be detected and blacklisted heuristically or by voting^.
Gridcoin has no technical dependency on particular ideologies or positions on a commercial-academic spectrum, and we shouldn't arbitrarily enforce a social dependency.
2. Manual whitelisting is very centralized.
Currently, whitelisting is implemented manually according to the results of a vote. This is flawed on several fronts. What happens if an administrator decides not to honor the result of a vote? What happens if one or all of the handful of administrators are disabled or unavailable to implement whitelist votes? What if someone is bribed to include a project that was never voted on?
There are too many ways this is potentially unhealthy for the network. It slows down the process of inclusion -- and also the process of excluding potentially bad projects. Much better to do this algorithmically to the fullest extent possible.
3. Whitelisting (as implemented, at least) is undemocratic.
Currently, the outcome of whitelist votes on Gridcoin are weighted by a combination of BOINC work credit and stakeholding. This means that the opinions of major miners and holders is grossly disproportionate to smaller miners and holders. There are arguments that these individuals are the most interested in the coin's "success" and most likely to vote in a "self-interested fashion" that presumably benefits everyone, but simultaneously people are arguing that Gridcoin's success shouldn't be determined by market cap, which means that the definition of "success" and "benefit" is not even agreed. We have many people who believe success should be a price and others who believe it should be scientific discoveries and nothing else.
From a sociological perspective, this process also means that a tiny demographic with unknown characteristics dominates the voting process, by definition in intrinsically biased ways, with potential consequences for the exclusion of particular types of science or commercial projects that do not meet this unknown demographic's norms or values. See the first point above for how this is a bad thing.
So what's a better alternative?
I strongly encourage the investigation and eventual adoption of an automated process where projects are submitted, analyzed, and included or rejected. For fraudulent or malicious projects, we can implement a blacklist similar to the current whitelist^. I don't propose any specific process here, only that our development community begin to investigate ways to automate this. We have some of the smartest people on the planet, so I'm sure we can come up with something that is less political, less centralized, and less oligarchic than the process we currently employ.
^ A small note about blacklisting: I believe blacklists should really be greylists, expiring after some period of time. Otherwise, they suffer from the same political weaknesses as whitelisting; for example, an unpopular project could be chasing some scientific insight that later is proved valid, but currently unpopular or in opposition to the voting demographic's norms and values. It would be better to quarantine these projects for some period of time, ideally long enough to kill off opportunistic parasites but not so long that it permanently fetters a valid project.
I don't know how I feel about it, although you're certainly right in terms of it being political. I personally like the whitelist and think it helps to boost projects which would otherwise maybe be overlooked, and additionally, doesn't allow one project with a very small number of crunchers to be awarded a disproportionate amount of the rewards.
I may be getting some technical pieces wrong though which might affect my judgement.
In any event though, let's have a conversation! Upvoted for visibility! Thanks for laying out all these thoughts.
Thanks for the open mind!
In theory, "very small number of crunchers" is one of those metrics that could result in an automatic delisting / greylisting. E.g., if a project runs for X hours / days and doesn't gain N% of the network, then exclude it. Or maybe a project has to have N% of the crunchers running it for a certain amount of time before it's automatically included, to prevent people from spawning little zombie projects just to steal GRC from the network.
Surely we can figure out how to do this without requiring a human to press the button.:)
I agree that the current process of maintaining the white-list requires too much interaction from both administrators and the community but i'm glad to see discussions on proposals to streamline the system.
If the Do you think Total Credit Delta is something that should be implemented in 2018 vote passes and is implemented the white-list will no longer require micro-management for projects that have a shortage of work and allow projects with intermittent work to be white-listed without causing the disproportionate payment issues that we have now.
I think we should avoid issuing polls to de-list projects that are causing disproportionate rewards and deal with the issue pro-actively through policy rather than re-actively through a series of individual polls. I feel that asking "Should {your favorite project} be removed due to lack of work units" invites community members to vote against maintaining a fair reward system. If a project is genuinely threatening the fairness of the payment system it should be quarantined (automatically or by an administrator) with a vote to de-list issued only if the work unit availability remains below a safe threshold for an extended period of time.
I support the proposals being discussed in the WU availability status for Gridcoin whitelisted projects thread as a policy to handle the quarantining of projects that cause disproportionate payments due to lack of work.
Polling also has a built in latency which makes it an inefficient means of dealing with temporary work shortages as the project in question may increase work flow by the time the poll is complete while potentially creating disproportionate payments during the time the poll was open.
The results of recent polls Should there be an enforced minimum BOINC project requirements checklist for whitelist status? and
What properties of whitelisted BOINC projects do you currently perceive to be equal?
show community support for including research based projects with adequate work availability and minimal to moderate project requirements, perhaps this could be a basis for automatic white-list approval with other projects accepted subject to a community poll.
Perhaps the number of Gridcoin registered CPIDs contributing to a project could be used as a trigger to begin the automatic white-listing process as members of the Gridcoin community will have already shown support for a project by being active contributors.
I think black-list vs white-list is really just a semantic difference at this stage of the conversation. Whether it is better to exclude all projects except for white-listed vs include all projects except for black-listed will depend on how the main issues in this thread are eventually handled in code.
Thanks for the detailed feedback.
I still think blacklist vs. whitelist is an important distinction because it's a matter of inclusion. As @limacoin said above:
A blacklist guarantees inclusion, even if only on a tiered basis, in exchange for the pain of setting everything up. Whitelisting means it's uncertain and a lot of people will never bother to do it in the first place since there's no guarantee of inclusion.
I think there should be opportunity for Gridcoin crunchers to vote with their feet and crunch any type of project they like, commercial or otherwise.
That is partly why I created the Gridcoin Rain in Python so that rain isnt limited to whitelisted projects as it is in the main client. Anyone can create a BOINC project, publish project/team stats in an XML, and they (or anyone else for that matter) could rain GRC to the crunchers, with that tool (use caution, Im not a pro developer!).
So then the Whitelist can remain political, and driven by altruism and self interests, as anyone can bypass it and reward BOINC crunchers with GRC in exchange for compute.
I like the way you think.:)
I think the main client should actually encourage this. It's my money, so why shouldn't I be allowed to rain it on whomever I like?:)
Thanks the pain is keeping the project xml feeds updated, I guess I should add an 'other' option so the user could just add their own URL, that would be easy.
The users must still be in team Gridcoin for it to work though.
Thanks for bringing this up. Perhaps there could be some progressive tier system so that the most trustworthy and work unit rich projects are given a higher status (and higher payout) compared to newer projects. Not to slant things too much in favor of these types of projects but enough of an incentive to help deter malicious/scammer/unreliable projects from taking over.
The different levels could look something like this:
0 - Blacklisted projects
1 - Grey list - In consideration for upgrade to white list level 1 pending some type of review/stats collection
2 - White list level 1 - Projects with a low level of WUs, or low security/low frequency of stats updates
3 - White list level 2 - Projects with a high level of WUs but low security/low frequency of stats updates
4 - White list level 3 - Projects that never run out of WUs and have proven themselves via publications etc. This type of project also has high security standards, reliable admins and frequent stats updates.
Unfortunately I think some degree of review from humans is necessary, otherwise I think the system could still be gamed to bring in bogus projects.
I actually like this idea a lot. I still think it should be largely automated, though. All systems can be gamed. It's basically like spam -- it's an arms race, but that doesn't mean it's not a worthwhile one.:)
This topic interests me and I think it should be brought up on next Gridcoin hangout.
In this way, I would like to invite you to Gridcoin Community Hangout. Check out @peppernrino, he will post the announcement+instructions soon. Hangout will be 6.1.2017
I personally think we should keep whitelisting projects rather than greylisting /blacklisting projects as is proposed by nateonthenet. It sets the hurdle higher at the beginning of the process of accepting new projects rather than trying to exclude a bad project after it is reviewed by the users, which might be even harder.
Although the majority of the BOINC projects are not-for-profit, I always thought GRIDCOIN is for-profit, and therefore we shall treat it as a company. So I do not see any problem that our votes are weighted by our assets and magnitude, I rather think it gives the right incentives for “crunching” and investing in GRIDCOIN.
But I would like to make another comment on your article as well as, the @Dutch’s process to set up a project under GRIDCOIN:
“Add Your Project to Gridcoin”
I think the whitelist process shall only apply for not-for-profit BOINC Projects, as GRIDCOIN generates COINs out of nowhere for these projects. However for a company and a for-profit use of BOINC and GRIDCOIN the implementation should be strait and bypass any whitelisting process. So GRIDCOIN is able to compete directly to the likes of SPARC, GOLEM etc.
No company, that would like to use the distributed computing power of BOINC, shall be obliged to invest first in setting-up a BOINC project, invest in the development of a working app and at the end be exposed to the approval of the community (If the project is whitelisted or not) waiting several weeks for the result of the vote.
Therefore I think the guide on www.gridcoin.science is highly misleading and should indicate, that this process only applies for new not-for-profit BOINC projects and not for comercial ones.
However I do think, there already exists a solution for the comercial use of BOINC power and GRIDCOIN, although quite a crude one: We should incentivize companies to use BOINC for their research and guide them as follows:
What we should be looking for, is the development of “Company” GRIDCOIN Wallet, which facilitates the payment to a large user base, or set-up a function for mass transfers to GRIDCOIN users besides the rain function in the existing wallet. I am convinced, this will generate a lot of (business-) opportunities for early adopters and our devs.
I disagree with the first part of your comment. My entire criticism is that "good" and "bad" are too subjective to be left to human fingers.
The second part is possible today with the use of Project Rain. See @scalextrix's comment below.:)
Since basically everyone can create BOINC projects just for fun i don't think blacklisting is the way to go. There are too many ways to exploit such a system, espacially if the amount of coins distributed is split fairly between all projects in the first step.
But i do see your point about commercial projects. I guess if you find enough support for such a project you could get it whitelisted.
About whitelisting being undemocratic, that's difficult to decide. Great holders have an interest in Gridcoin to advance and crunchers are by all means very important to Gridcoin, otherwise this was just a boring PoS-coin. So people who contribute much processing power or at least own decent amounts of grc also got to point a direction this project is going. I think this is a democratic process.
Also giving more voting power to possible bots who neither crunch nor bought gridcoin is a possibility to attack the values of this coin
Don't be lazy! ;) Surely we can find ways to automatically stage in projects so that the odds of a bad project being fully included is minimal, and the few that get through are still able to be blacklisted / greylisted. We just have to be willing to think about how to do it. Enumerating potential exploits is a good way to help come up with a system to prevent them, so if nothing else doing that would be helpful.:)
I think you maybe misunderstood something, because nowhere did I suggest giving anyone more voting power.:)
I think, this problem is ideal for another survey poll.
I guess you could say it's political but just like with Steemit, those with the most at stake have the greatest influence. This doesn't seem entirely unreasonable to me. I do agree that centralization is generally undesirable though.
White-list poling certainly could be performed in a political manner even if it isn't necessarily the case at the moment.
I would argue that GRC investors don't need to be involved in white-list polls since coins are minted at a predictable rate regardless of how they are distributed (please correct me if i'm wrong here).
It's only the miners who should be directly concerned with the fair distribution of mining rewards and the inclusion of projects that they are contributing to.
Of course changing to a purely magnitude based poll for white-list voting still allows for political influence within the mining community but at least then the voting share is directly proportional to the amount of mining contribution rather than financial investment in the currency.
Automating the process of project inclusion would remove the need for voting and ease the threat of project exclusion for ideological reasons so it would be a good feature to aim for.
I totally agree with the automated aspect of the future improvement. Althought I'm not sure of the implications of granting private funded projects the access to Gridcoin network : say, if 2 equivalent projects technically and logistically speaking, but one is public and the other one is private, are the Gridcoin workers of the private one rewarded differently than those of the other one ? I guess the answer is yes. They may have chosen the private one for profit. But from the point of view of Gridcoin, this implies a lot more effort to manage these two types of philosiphical positions. And this has a cost. So, for me, I see only one solution : Gridcoin should pay less the private participants (to cover the costs) and the complement should be brought by the private institute who claims the network. And this can be a criterium to select which private institute is motivated enough to enter the arena. If it agrees to give Gridcoins enough for the participants to be more rewarded than the public ones (techn. and logis. equivalent) then it is becomes a private partner institute. And I think Gridcoin should stay as faithful as possible to its respectful views regarding those who absolutely don't want to talk about money. Faith or less, in a way.
I'm not sure I agree, but it's an interesting distinction. One tricky part is how you'd determine private vs. public status of projects -- there is plenty of grey there, probably enough to make it not worth trying to enforce that distinction.
That's not Gridcoin which should determine private from public. It's up to the institute itself, or better the project in question, to declare itself public or private at sign up. If they declare themselves as public then all is like before (they don't profit from a particular growth in network population ). If they declare them private then they should provide a guarantee that Gridcoin workers will be well rewarded to compensate Gridcoin tax. And then they profit from a big network of hungry crunchers!