This is the third and final post in a short series analyzing and comparing the security of Recent Average Credit (RAC) and Total Credit Delta (TCD). (Links: first post, second post.)
This post examines the fairness of RAC and TCD in situations where projects are added or removed from the whitelist. Can one unfairly gain GRC by cleverly allocating resources? As it turns out, one can (to an extent). These potential 'exploits' are important to consider when implementing both TCD and whitelist/greylist protocols.
.
Suppose you are crunching project Y, and a 30-day poll opens to whitelist project X. You want to crunch X because you are excited about the science. Moreover, you are convinced the poll will go through successfully. Given this confidence, is there any way to maximize your earnings by cleverly re-allocating compute power to project X? Indeed there is, which I’ll call the 'first-mover' advantage. Let’s look at it first in the case of RAC.
Additional assumptions: You have been maintaining a constant magnitude on project Y. On day 1, the 30-day poll for project X opens. You know that by crunching on X, you will accumulate the same magnitude as you have on Y. Moreover, no one else starts crunching until day 30, when the project is whitelisted (apparently, no one else is aware of your 'clever' strategy). For definiteness, let’s consider a 60-day interval, and compare two strategies:
Denote the earnings in either case as E1 and E2. Which one gets you the most GRC?
Answer: E2, with the optimal n sitting around 19. This is shown in the plot: Starting to crunch on day 19 (before the project is whitelisted) gets you about 15% more GRC. In other words, you are receiving rewards for work done before the project is whitelisted. I don’t think this is fair.
Is this more than a theoretical demonstration? Yes. I can confirm that individuals (including myself) have taken advantage of this strategy in the past, and the extra rewards are real.
A good thing about TCD is there is little advantage to start crunching on a project prior to whitelisting, since TCD doesn’t build up over time. On the other hand, it will take at least a couple of days for news of whitelisting to percolate through the community, people to transition/set up their rigs, and initial work units to be completed and credits calculated. This would be particularly significant if the project were just coming off the greylist. If a greylist --> whitelist transition happened without warning between superblocks, there could be an unfair advantage to the 'insiders' on the greylisting protocol. Thus, I suggest we consider a wait period of at least a couple of days following approval before a project actually appears in a superblock. There should also be a mandatory procedure for making the announcement readily visible to all community members.
Now, I will say the following (assuming TCD is used): Having given everyone in the community ample opportunity to make themselves aware of whitelist changes, I actually don’t think it’s a bad thing if particularly cognizant individuals start submitting WUs the second a project shows up in a superblock, and correspondingly find themselves with a small initial advantage. We want project admins to be able to rely on consistent compute power from day 1, rather than languishing through days of dead time while crunchers slowly come on board. Thus, it actually makes sense to ‘pay’ a little extra to those who carefully follow whitelist news and rapidly allocate resources accordingly. The sticking point is that the same opportunity should be afforded to everyone in the network, no complicated calculations (as for RAC) or insider information involved.
There are a few conclusions from these posts I want to emphasize:
I hope these posts will prove a useful resource when the time comes to code up TCD for real.
