RAC versus TCD: Case Study 2

This is the second in a short series of posts analyzing and comparing the security of Recent Average Credit (RAC) and Total Credit Delta (TCD).  

In the first post, I showed that for fixed team Gridcoin performance (i.e. constant overall RAC and TCD), there is no motivation for small miners to submit work units (WUs) unequally across time. Thus, for instance, there is no benefit in ‘spiking’ RAC by saving up completed WUs and submitting all at once. For big miners, there is actually a small incentive for distributing computing power uniformly across time (and projects).  

In this post I will look at a more interesting case, where TCD – and to a much smaller extent RAC – can be manipulated to unfairly obtain rewards under certain special circumstances. In the current version of Gridcoin, which is based on RAC, this ‘exploit’ is quite minor, so no need to panic. However, for TCD it is more serious and warrants appropriate countermeasures.

And so we begin… 

The Premise

Tucked away in the BOINC preferences, you will find this field: 'Store at least: X days of work'. The default is 0.1 days, but there doesn’t appear to be sharp upper limit on how many days you can choose. Does this functionality lay the groundwork for an exploit?  

Imagine the following. You set X equal to 7 days, so at any given time you have at least 7 days’ worth of work. Now, suppose the project is depleted of WUs for a week. The crunchers who were not wise to the caching functionality will quickly run out of new work. Let’s say that within ~2 days, the majority of trailing edge tasks are submitted and credits have been calculated, so for all practical purposes these crunchers will not be gaining any more credits. You, on the other hand, were clever enough to have a cache of a week, which means you can maintain your regular output throughout the whole 7 days that the project is out of new WUs. You get the idea: Since your magnitude is normalized by the total output of team Gridcoin at any time, you will get an unfairly high magnitude during the week of WU depletion. How bad is this ‘exploit’? Let's see in the next section.

Analysis

Assumptions: Excluding yourself, team Gridcoin’s output (in credits/day) is constant on days 1 and 2, zero on days 3-7, and constant again thereafter. I will only focus on days 3-7, and in particular ignore any 'recovery period' in which the overall RAC grows to its original value. Calculation of RAC and corresponding rewards follows the simplified model discussed here.  

RAC 

Suppose prior to WU depletion, your fraction of total team Gridcoin RAC is f. Let E be your 5-day earnings during a normal week without WU depletion, and let E' be your earnings with WU depletion. The plot shows E'/E. For small miners, you get about 35% extra rewards; for large miners this tapers off since you are competing with yourself. The absolute most GRC you can get unfairly occurs when f is about 0.45 and corresponds to ~7% of the GRC allocated to the project. How much is this? Well, based on the current GRC distribution scheme, < 100 GRC/day. Not a huge amount. Given all the pieces that would have to fall into place to realize this worst-case scenario, and given the unpredictability of RAC in practice, it’s safe to say that we don’t need to panic about this ‘exploit’.  

TCD 

The situation is somewhat different here. TCD does not smooth over time like RAC does, and therefore the worst-case scenario in fact corresponds to (unfairly) receiving all the GRC allotted to a project in a span of 5 days. This isn’t even hard to achieve – all you have to do is submit some work during the dead period when no one else has WUs to submit. This is a problem. 

Discussion 

RAC has a minor ‘exploit’ which is not worth panicking about. TCD has a serious exploit that must be considered when working out an implementation. 

Appropriate countermeasures might include: 

1. Upping awareness of the BOINC ‘cache’ functionality. The more people who use this functionality, the more the ‘exploit’ gets diluted. 
2. Requiring all whitelisted projects to cap the WU cache size at an appropriate value. Most likely, at least some limit is already in place for existing projects, c.f. this text from World Community Grid’s FAQ: “Please do not use values longer then 4 days, as the scheduling algorithm in the client may prevent you from getting as much work as you would like.”
3. (The most important one) Build a mechanism which boots projects from the whitelist if their WU availability drops below some critical value for more than ~1-4 days. 

 More next week…!  

Note added: For those unfamiliar with Gridcoin, the above discussion ONLY has to do with distribution of new Gridcoin to miners. It has nothing to do with the security of the blockchain, which is secured via PoS. So even the worst-case scenario in the current RAC-based implementation only results in a small amount of Gridcoin being unfairly distributed, nothing else.