RAC versus TCD: Case study 3
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.
The first-mover advantage
.
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.
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:
- Transition to X the day it is whitelisted.
- Transition to X on day n, where 1 <= n <= 30.
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.
TCD
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:
- RAC is messy.
- TCD is simple.
- Both RAC and TCD have 'exploits'. The exploits for TCD are more severe than for RAC.
- Properly implemented, TCD is superior to RAC.
I hope these posts will prove a useful resource when the time comes to code up TCD for real.
Do you think the potential TDC exploits would be as much of a concern if daily mining rewards were normalized across all of BOINC rather than per project?
That's a good point. In that case the exploits would definitely be less of a concern since they would be 'diluted' across multiple projects.
Recently there were a couple of suggestions on how to normalize rewards across all of BOINC: here and here. It seems the challenge lies in calculating magnitude consistently (and securely!) across projects and hardware types. It appears unlikely we'd solve these issues in the near term, but I think the suggestions are definitely worth keeping in mind in the long term.
I have followed those posts and at first I wasn't sure why globally normalizing credit should be a priority but as I am gaining a better understanding of how the current systems are all so very dependent on each other and that there will be a ripple effect for any of the v4.0 road map items.
It seems like traditionally the fairness of payments has come at the cost of flexibility and as improvements are made that allow flexibility in the network fairness is being threatened.
Right. I think we can still get a fair reward system running, but yeah we'll have to be more deliberate about it with the v 4.0 roadmap simplifications.
Well said, that sums up the way I feel about the situation.
Very good case studies, thank you. I think the hoarding WU exploit you mentioned in previous posts is something that we should keep an eye on. As far as I know, there's no way to verify for certain that it's happening, so observation may be the only way. If it ends up being a problem we should look into some of the proposals you mentioned.
Sure, thanks! Although I think some preemptive action is warranted, I agree this should be accompanied by real-time monitoring to see whether the initial countermeasures were sufficient. We could even set a small bounty for anyone who can demonstrate a significant enough exploit in practice ;)
I agree, but what would it look like? You made some proposals in your last post, but the first two require direct changes in BOINC, which in my understanding is something both the GridCoin community and the BOINC community want to avoid. The third one is sort-of addressed by the greylist, but maybe it could be improved.
That's a good idea, I think it is possible this will be occurring the more popular GridCoin becomes.
Hmm.. well to be honest, the first two proposals I just kinda threw out there because. The third proposal is the main one. That being said, I don't think the first two involve changes to BOINC, since the caching function is already built into the source code. We'd just be changing the way users and project admins alike approach that functionality.
Anyways, I think a carefully constructed greylisting procedure would be a pretty solid fix to the potential exploits. In the context of the current post, we'd just need to buffer changes to the whitelist with sufficient forewarning to prevent exploitation by insiders on the process.
Sounds reasonable. Any particular buffers in mind? Or do you think another analysis would be necessary?
Congratulations @h202! You have completed some achievement on Steemit and have been rewarded with new badge(s) :
Click on any badge to view your own Board of Honor on SteemitBoard.
For more information about SteemitBoard, click here
If you no longer want to receive notifications, reply to this comment with the word
STOP