I originally started a discussion over at cryptocointalk about this: https://cryptocointalk.com/topic/46130-discussion-3rd-generation-boinc-credit-system/

An user on /r/boinc felt that I should have posted the topic to the official BOINC message boards, so I'm crossposting the topic to here.

The latest (2011/2012) information I've found that discuss the credit system and cheating are the two following publications:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6332291
http://​http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6008859&queryText=boinc&pageNumber=3&newsearch=true

All other discussions/topics on the credit mechanism are from 2008.

Creditnew wiki entry: https://boinc.berkeley.edu/trac/wiki/CreditNew

The first credit system
In the first iteration of BOINC's credit system, "claimed credit" C of job J on host H was defined as
C = H.whetstone * J.cpu_time
There were then various schemes for taking the average or min claimed credit of the replicas of a job, and using that as the "granted credit".
We call this system "Peak-FLOPS-based" because it's based on the CPU's peak performance.

The problem with this system is that, for a given app version, efficiency can vary widely between hosts. In the above example, the 10 GFLOPS host would claim 10X as much credit, and its owner would be upset when it was granted only a tenth of that.

Furthermore, the credits granted to a given host for a series of identical jobs could vary widely, depending on the host it was paired with by replication. This seemed arbitrary and unfair to users.

The second credit system
We then switched to the philosophy that credit should be proportional to the FLOPs actually performed by the application. We added API calls to let applications report this. We call this approach "Actual-FLOPs-based".

SETI@home's application allowed counting of FLOPs, and they adopted this system, adding a scaling factor so that average credit per job was the same as the first credit system.

Not all projects could count FLOPs, however. So SETI@home published their average credit per CPU second, and other projects continued to use benchmark-based credit, but multiplied it by a scaling factor to match SETI@home's average.

This system has several problems:
•It doesn't address GPUs properly; projects using GPUs have to write custom code.
•Project that can't count FLOPs still have device neutrality problems.
•It doesn't prevent credit cheating when single replication is used.

Goals of the new (third) credit system
•Completely automated - projects don't have to change code, settings, etc.
•Device neutrality
•Limited project neutrality: different projects should grant about the same amount of credit per host-hour, averaged over hosts. Projects with GPU apps should grant credit in proportion to the efficiency of the apps. (This means that projects with efficient GPU apps will grant more credit than projects with inefficient apps. That's OK).
•Cheat-resistance.

Cheat prevention
Host normalization mostly eliminates the incentive to cheat by claiming excessive credit (i.e., by falsifying benchmark scores or elapsed time). An exaggerated claim will increase host_app_version.pfc_avg, causing subsequent credit to be scaled down proportionately.

This means that no special cheat-prevention scheme is needed for single replications; in this case, granted credit = claimed credit.

However, two kinds of cheating still have to be dealt with:

One-time cheats
For example, claiming a PFC of 1e304.
This is handled by the sanity check mechanism, which grants a default amount of credit and treats the host with suspicion for a while.

Cherry picking
Suppose an application has a mix of long and short jobs. If a client intentionally discards (or aborts, or reports errors from) the long jobs, but completes the short jobs, its host scaling factor will become large, and it will get excessive credit for the short jobs. This is called "cherry picking".

The host punishment mechanism doesn't deal effectively with cherry picking.

The following mechanism deals with cherry picking:
•For each (host, app version) maintain "host_scale_time". This is the earliest time at which host scaling will be applied.
•For each (host, app version) maintain "scale_probation" (initially true).
•When send a job to a host, if scale_probation is true, set host_scale_time to now+X, where X is the app's delay bound.
•When a job is successfully validated, and now > host_scale_time, set scale_probation to false.
•If a job times out or errors out, set scale_probation to true, max the scale factor with 1, and set host_scale_time to now+X.
•When computing claimed credit for a job, and now < host_scale_time, don't use the host scale factor

The idea is to use the host scaling factor only if there's solid evidence that the host is NOT cherry picking.
Because this mechanism is punitive to hosts that experience actual failures, it's selectable on a per-application basis (default off).
In addition, to limit the extent of cheating (in case the above mechanism is defeated somehow) the host scaling factor will be min'd with a constant (say, 10).


Sanity check

If PFC(J) is > wu.fpops_bound, J is assigned a "default PFC" D and it's not used to update statistics. D is determined as follows:
If app.min_avg_pfc is defined thenD = app.min_avg_pfc * wu.fpops_estOtherwiseD = wu.fpops_est

3rd gen credit mechanism proposal?
https://boinc.berkeley.edu/trac/wiki/CreditProposal

Proposal for a new credit system
This is a tentative proposal for a new credit system for BOINC.

Requirements
•The system should reflect how much "utility" volunteers provide to projects. There are many types of utility (see below). Projects should be able to define utility however they want.
•The system should normalize the amount of credits given by different projects, so that there will be no incentive for average volunteers to select projects based on credit (however, volunteers with unusual computers should have an incentive to select projects that need such resources).
•The average amount of credit per host per day should remain constant over time.

Types of utility
Possible types of utility:
•Computation (FP, integer, or mixed) without tight deadlines (this is typical of most current projects).
•Computation with a tight latency bound (minutes or hours).
•Computation that needs a large amount of RAM.
•Computation that needs a large amount of storage.
•Storage (e.g. GB/day).
•Storage, with network bandwidth and/or availability requirements.
•Network bandwidth (e.g. web crawling).
•Network bandwidth at particular times of day (e.g. Internet performance study).
•Deployment on a wide range of computer types (e.g. studies of computer usage).
•Computation with human "steering".
•Human activity (e.g. Stardust@home-type projects).

Proposal
•Computers are described by a set of parameters (FP and int benchmarks, #CPUs, cache sizes, memory bandwidth, available RAM, available disk, presence of particular GPUs, network bandwidth, available fraction, connected fraction, maybe others).
•Each project P publishes a "credit function" C(H) specifying, for a host H with given parameters, how much credit per day would be granted if H is attached exclusively to P.
•Normalization rule: for each project, the average of C(H) over all hosts participating in BOINC must be about 100.
•Accounting rule: the credit granted by a project P cannot exceed the sum over hosts H of RS(H, P)*C(H) where RS(H, P) is the fractional resource share of H's attachment to P.
•The normalization and accounting rules would be evaluated by cross-project statistics sites.

Examples
•Computational projects would have to derive a credit function based on how fast various types of computers run their applications (and how much they value each application). We can supply automated tools for this.
•Suppose a project's application needs at least 16 GB RAM. Its credit function would be zero for hosts with < 16 GB RAM. •Its value for hosts with at least 16 GB would be limited by the normalization rule.
•For a storage-only projects, C(H) would be proportional to available disk space (possibly with some additional consideration for network bandwidth etc.).
•Using the published credit functions, it would be possible to develop a "credit maximizer" web site, where users can enter the parameters of their computer, and it tells them how much credit/day each project would give them.
•Similarly, it would be possible to develop a web site that tells users how much additional credit/day they could get by adding more disk/RAM/network bandwidth etc. to an existing computer.

Questions and comments
•BOINC doesn't currently have code to measure memory bandwidth or cache sizes; we'd need to develop this.
•How should credit functions be represented (e.g., as a data structure? a PHP function?).
•What should the default credit function be? What tools can we provide to projects to let them develop appropriate credit functions easily?
•As computers become faster and bigger, credit functions will have to change in order to continue to satisfy the normalization rule.
•Credit can no longer be used as a basis for FLOPS estimates; we'll need something else for that purpose (or keep around the existing credit system and use it only to estimate FLOPS).
Suppose a project's application needs X GB of RAM, and there is only one host in the BOINC population with that much RAM. Then its credit per day for that host can be 100N, where N is the size of the population. In other words, that computer can get as much credit as all other computers combined. Is this desirable?
The accounting rule doesn't take into account non-competing projects. E.g. suppose project A uses only CPU and project B uses only disk. If hosts attach to both projects with equal resource shares, the projects will be limited to issuing 50 credits/day on the average.
•Suppose a project uses a resource that other projects use little or none of (e.g. QCN uses the accelerometer found in some laptops; Depspid uses network). How much credit should the project be allowed to grant? Under the current proposal, they would be allowed to grant something like 100/(N+1) per host/day, where N is the average number of other attached projects.
•Also in the above case, the resource share for QCN doesn't affect its utility (since it doesn't use any bottleneck resources), and yet users' resource share settings will affect how much credit can be granted by QCN and other projects attached to hosts running QCN. This doesn't seem right.
•Suppose that a large number of projects arise that don't use CPU or other bottleneck resources. If they're allowed to grant as much credit as CPU-intensive projects, then credit becomes meaningless.
•This proposal doesn't say anything about the last 3 types of utility.

Interesting links (papers/old threads):

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6332291
http://boinc.thesonntags.com/collatz/forum_thread.php?id=195
https://boinc.berkeley.edu/dev/forum_thread.php?id=2403#14747
http://comments.gmane.org/gmane.comp.distributed.boinc.user/4184
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6008859&queryText=boinc&pageNumber=3&newsearch=true

The equivalent reference document hosted locally is http://boinc.berkeley.edu/trac/wiki/CreditNew. Because that's held as a Wiki, you can look back through the history, timeline, and (sole) authorship of how it evolved.

The equivalent reference document hosted locally is http://boinc.berkeley.edu/trac/wiki/CreditNew. Because that's held as a Wiki, you can look back through the history, timeline, and (sole) authorship of how it evolved.

Ah, I forgot to add a direct link to the wiki page - I've added it to the main post, thanks.

Should we link to this thread in the developer mailing lists? Or do you believe this topic will gain enough attention on its own in this message board?

So what's the goal of your discussion? You want to find out how a fourth credit systems should be like? I would be interested to discuss this too.

But first one has to discuss the meaning of Credits and if they should really be comparable between projects or if they should be only comparable between the different applications of a project (which is difficult enough).

I think he brings it up because "cheating" can impact Gridcoin payouts. So, there is a financial and stability issue with their cryptocurrency payout system that they are probably hoping to fix. But, I have not read up on it much as I don't care about cryptos all that much.

---

So what's the goal of your discussion? You want to find out how a fourth credit systems should be like? I would be interested to discuss this too.

The goal is to renew the discussion of a potential 3rd gen BOINC credit system, hopefully leading to an agreed 3rd gen credit system proposal that can extend functionality and eliminate potential cheating.

I answered a very similar question over on cryptocointalk: https://cryptocointalk.com/topic/46130-discussion-3rd-generation-boinc-credit-system/#entry213012

I read the Malikcredit publication ( http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6332291 ), I haven't been able to find any public discussion regarding it nor the 3rd gen proposal. The proposed change from Whetstone/Drystone to MalikStone sounds logical (albeit it does not cover memory/bandwidth/storage benchmarks).

But first one has to discuss the meaning of Credits and if they should really be comparable between projects or if they should be only comparable between the different applications of a project (which is difficult enough).

Currently, the Gridcoin network rewards BOINC projects on an individual project basis, so one project rewarding 1000 vs another project rewarding 10 for an WU does not currently affect us too badly. It's a similar project credit comparison method as the one formulaboinc uses: http://formula-boinc.org/

I understand what you're meaning though, BU rewarding RAC on a far higher scale than other projects does devalue the combined RAC leaderboards somewhat. A new credit system could potentially propose an alternate method of dealing with FPGAs/ASICs.

Cherry picking of individual applications within a project (one that rewards a higher score over other project applications rather than attempting to verify your WU's with another computer) is a problem on an individual BOINC project basis, no? Can you think of some method of mitigating this?

I think he brings it up because "cheating" can impact Gridcoin payouts. So, there is a financial and stability issue with their cryptocurrency payout system that they are probably hoping to fix. But, I have not read up on it much as I don't care about cryptos all that much.

Indeed, the main reasons for pursuing the discussion/development of the 3rd gen credit system are the following:
1. Cheating the BOINC credit system allows users to earn Gridcoin fraudulently - this undermines the integrity of Gridcoin's Distributed Proof of Research reward mechanism.
2. I'm campaigning for the removal of the team 'gridcoin' membership requirement in the gridcoin system in order for all BOINC users to earn Gridcoin, not just one team. Due to the recent discovery of cheaters within and outwidth team Gridcoin, the team membership requirement has temporarily been deemed a neccessary evil in order for team founders to kick discovered cheaters from team gridcoin (cutting off cheaters from earning gridcoin fraudulently).
3. Despite team founders being able to kick users from the team, it's difficult to prove cheating (especially when users hide their hosts). This places team founder users in a difficult centralized position of power.

If cheating gets unmanageable, removing individual affected projects from the whitelist (ending distribution of gridcoin for work completed for a project) is a highly likely outcome.

Quick meta question: After a set period of time, does a post's 'edit' button/functionality dissapear?

Quick meta question: After a set period of time, does a post's 'edit' button/functionality dissapear?

Yes. I believe it's 1 hour.

---

Kathryn :o)

First. Please call this new Credit system the 4th generation Credit system. CreditNew, as it is widely called, is actually the third Credit system in BOINC (clearly stated on the CreditNew page).

I also read the MalikCredit paper and although it does not say so it is based on the second Credit System (the one before Credit New) and is a bit outdated and also suffers from the problem that the benchmark is reported by the Client and thus can be cheated. There are other assumptions in the MalikCredit paper that are not practical for all projects. I still have to find the MalikStone paper to read about the benchmark.

I would like to start with a list of requirements a new CreditSystem should have. I would also like to centralize the discussion and not have two places with different people (here and at cryptocointalk).

Lastly I wold also like to point to this proposal that came shortly after the rise of BitcoinUtopia: http://boinc.berkeley.edu/trac/wiki/CreditGeneralized

Regards
Christian

First. Please call this new Credit system the 4th generation Credit system. CreditNew, as it is widely called, is actually the third Credit system in BOINC (clearly stated on the CreditNew page).

My mistake, I thought that "Goals of the new (third) credit system" meant that creditnew was the 2nd generation credit system.

I also read the MalikCredit paper and although it does not say so it is based on the second Credit System (the one before Credit New) and is a bit outdated and also suffers from the problem that the benchmark is reported by the Client and thus can be cheated. There are other assumptions in the MalikCredit paper that are not practical for all projects. I still have to find the MalikStone paper to read about the benchmark.

I've skimmed through it, it doesn't cover all 4 of the proposed types of credit in the 'CreditGeneralized' credit system proposal, but it does suggest improvements to the 'Computing credit' which could apply to the 'CreditGeneralized' proposal.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6266936
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6641472

You're right though, we could create benchmarks for the 4 proposed types of credit (Computing credit, Storage credit, Network credit, Project-defined credit) but ultimately since it's ran on the client's side, it could be potentially manipulated.

Any ideas how to prevent local cheating of benchmarks?

I would like to start with a list of requirements a new CreditSystem should have.

Shall we use [google docs/requirements management software/this forum] for documenting these requirements?

I would also like to centralize the discussion and not have two places with different people (here and at cryptocointalk).

We can certainly consider this thread to be the main thread for this discussion, however I'll probably continue using the cryptocointalk thread for gridcoin related discussion of the credit system.

Regarding the 1 hour edit rule on this forum - are we able to change this on an individual thread/post basis? Or is a post uneditable once the edit button dissapears? Editing would be very handy when documenting proposed requirements.

Lastly I wold also like to point to this proposal that came shortly after the rise of BitcoinUtopia: http://boinc.berkeley.edu/trac/wiki/CreditGeneralized

Regards
Christian

I hadn't seen this, thanks for linking this credit system proposal. It raises several good ideas that should potentially be considered.

I would like to start with a list of requirements a new CreditSystem should have. I would also like to centralize the discussion and not have two places with different people (here and at cryptocointalk).

This is definitely needed (with any system). I guess this raises the question, where exactly is the functionality defined and what is the the right forum for discussion?

I don't feel the current credit system is broken enough, but there are inconsistencies between projects and apps, which could be better normalized.

To help normalize, i feel a need to redress the lack of application profiling data, across projects, both as a reference and in real-time, so that reasonable values of credits can be assigned, and monitored.

The data would help users (and eventually boinc) decide where to invest their resources, eg I have little network bandwidth so steer away from those credits. It would help developers tune their apps, and project owners see their apps compared to others.

Lastly I wold also like to point to this proposal that came shortly after the rise of BitcoinUtopia: http://boinc.berkeley.edu/trac/wiki/CreditGeneralized

It's not clear who the author(s) were - was it captured from a forum?

I would like to start with a list of requirements a new CreditSystem should have. I would also like to centralize the discussion and not have two places with different people (here and at cryptocointalk).

Lastly I wold also like to point to this proposal that came shortly after the rise of BitcoinUtopia: http://boinc.berkeley.edu/trac/wiki/CreditGeneralized

I think there are at least two expectations on what a credit system should do:

First, of course, users should be able to compare themselves with each other. Without some numbers reflecting the work they have done, there would be no competition, no challenges or races, no funny badges, etc., i.e. less incentive for many users.

Second, from a more scientific point of view, it would be nice to have some project-wide and even BOINC-wide numbers reflecting the performance in FLOPS, bandwidth, etc. Publications could easily compare the project's performance with supercomputers and if someone asks about the total performance of the BOINC network, we would have a real answer instead of a rough estimate.

Obviously, to match the second expectation, more quantities have to be measured, just like the CreditGeneralized proposal suggests. To match the first expectation, however, the credit system should follow the KISS principle. The CreditGeneralized proposal definitely isn't KISS and opens new cans of worms:

- If only FLOPs are counted, how to deal with applications doing mostly integer arithmetics? Should they just grant less credit in this category or should we (again) count some FLOP equivalent unit rather than actual operations on application level? Of course, if we wanted to count actual operations, all applications would have to be modified, which certainly is not going to happen.

- Regarding storage usage: Some projects need lots of disk space just to store some data that is not used all the time, while there are also applications that do many read and write operations. What exactly would we want to measure? Why? How?

- Regarding network usage: How to stop a funny guy reattaching to Rosetta@home after every finished workunit, just to have their huge database file downloaded every time again in order to get as many network credit as possible? Just don't count sticky files? If yes, why?

- Any number measured on the client side might be cheated. Just saying, "We'll figure out how to make them cheat-resistant", doesn't solve this problem. It might be possible to make it ridiculously hard to manipulate the measurements, but I'm sure that eventually someone will come up with a manipulated BOINC client or find out how the measured numbers are transferred to the server.


Therefore, I'd suggest disentangling the "competitive" and the "scientific" credit systems:

- Measure FLOPS, memory usage, disk usage, network usage, whatever you like, on per-host level. The results might be shown on the host details page (like it is already the case for some information, e.g. hostname, on_frac, active_frac). Compute the total numbers on project level and show them on the server status or the home page. Don't create any leader boards with it and don't export per-user or per-team data to keep the incentive for cheaters as low as possible.

- For competitive reasons, keep track of something that is close to what the CreditGeneralized proposal calls "Project-defined credit". Leave it entirely to the projects in which way they want to grant credits. For most projects, this would likely be just what they already do. For new projects, make it as easy as possible for the administrators to implement their own system. As a starting point, the most easy credit system you can think of (i.e., just counting valid workunits, which is of course unfair in case of workunits with variable lengths... but, to be honest, the current CreditNew "system" also works best for fixed-length workunits) might be set as a standard until the administrators implement something they like better.

Of course, this approach only bypasses the first of the "undesirable consequences" mentioned in the CreditGeneralized proposal (i.e., "Credit no longer measures FLOPs", which is not a problem any more because FLOPs can be derived from the separated FLOPS measurements instead).

It fixes neither "The [BOINC-wide] competitive balance between volunteers is lost." nor "The competitive balance between projects is lost.". But I think that these goals are unreachable anyway (hard enough to find fair solutions for multiple subprojects of the same project) and they're not even too problematic:

- Obviously no problem for single-project competitions. If you are crunching project A instead of project B because you get "more credit" on A, you simply don't get any credit on B and won't win any competition there.

- It is already proven that multi-project competitions that work nicely without "cross-project parity" are possible (DC Vault, Formula BOINC, BOINC Pentathlon). More traditional third-party long-term stats may apply any normalization they like, normalization doesn't need to be done by the projects. Of course, they're also free to continue showing meaningless sums (the sum is just like giving 'three fruit' to someone... he won't know if he will be full after eating them before he learns if it's three strawberries or one melon and two oranges).

- In real life, there are similar problems for which you can find arbitrarily many 'fair' solutions depending on the point of view. Should the football player really earn lots of money because he can do his job for a shorter period of time and has a higher injury risk than the old people's nurse? Life still goes on.

Finally, my suggestion doesn't attack the problem that the "Project-defined credit" might be cheatable. But as it leaves the credit system up to the individual projects, there's neither a general solution nor should that topic be discussed here. However, my suggested as-simple-as-possible standard system is at least resistant to manipulation of benchmarks or computing time.

---

I think he brings it up because "cheating" can impact Gridcoin payouts. So, there is a financial and stability issue with their cryptocurrency payout system that they are probably hoping to fix. But, I have not read up on it much as I don't care about cryptos all that much.

Indeed, the main reasons for pursuing the discussion/development of the 3rd gen credit system are the following:
1. Cheating the BOINC credit system allows users to earn Gridcoin fraudulently - this undermines the integrity of Gridcoin's Distributed Proof of Research reward mechanism.
2. I'm campaigning for the removal of the team 'gridcoin' membership requirement in the gridcoin system in order for all BOINC users to earn Gridcoin, not just one team. Due to the recent discovery of cheaters within and outwidth team Gridcoin, the team membership requirement has temporarily been deemed a neccessary evil in order for team founders to kick discovered cheaters from team gridcoin (cutting off cheaters from earning gridcoin fraudulently).
3. Despite team founders being able to kick users from the team, it's difficult to prove cheating (especially when users hide their hosts). This places team founder users in a difficult centralized position of power.

To be honest, I don't know too many details of how Gridcoin works and my interest in it is not strong enough that I'd want to do much research on it. But as I might just not see the obvious, I'd like to know where exactly you see that team membership requirement being necessary to hold off cheaters from getting Gridcoins.

What happens with a user's Gridcoins if he leaves or is kicked from team Gridcoin? Does he lose them? Does he keep them but can't use them for anything anymore? If he keeps them and still can use them, the "damage" has already been done at the time the user is kicked.

Additionally, AFAIK, there's no way to prohibit a kicked team member joining the team again (it can only be closed for all not-members). Even if there was a way, the cheater might just create a new account.

If cheating gets unmanageable, removing individual affected projects from the whitelist (ending distribution of gridcoin for work completed for a project) is a highly likely outcome.

Well, although the Gridcoin homepage says "The BOINC RAC system has existed for many years and has proven uncheatable.", it just hasn't. I've been BOINCing for more than ten years and I've seen more or less massive cheating going on all the time. Over the years, almost all projects were affected. Faked benchmarks on projects using the first, benchmark-based credit system, and the CreditNew lottery in recent days were only the tip of the iceberg. In at least one case, even the scientific results were compromised... and back then, there were only credits and badges, Gridcoins might be an additional incentive for some.

Why don't you remove the projects from the whitelist before the damage is done, i.e. removing all projects where cheating occured?

Somehow a picture crosses my mind that the people behind Gridcoin try to build an additional floor onto a house (BOINC), but while they know a lot about their building materials (cryptocurrencies), they don't yet understand the statics and the architecture of the house.

---

I think he brings it up because "cheating" can impact Gridcoin payouts. So, there is a financial and stability issue with their cryptocurrency payout system that they are probably hoping to fix. But, I have not read up on it much as I don't care about cryptos all that much.

Indeed, the main reasons for pursuing the discussion/development of the 3rd gen credit system are the following:
1. Cheating the BOINC credit system allows users to earn Gridcoin fraudulently - this undermines the integrity of Gridcoin's Distributed Proof of Research reward mechanism.
2. I'm campaigning for the removal of the team 'gridcoin' membership requirement in the gridcoin system in order for all BOINC users to earn Gridcoin, not just one team. Due to the recent discovery of cheaters within and outwidth team Gridcoin, the team membership requirement has temporarily been deemed a neccessary evil in order for team founders to kick discovered cheaters from team gridcoin (cutting off cheaters from earning gridcoin fraudulently).
3. Despite team founders being able to kick users from the team, it's difficult to prove cheating (especially when users hide their hosts). This places team founder users in a difficult centralized position of power.

To be honest, I don't know too many details of how Gridcoin works and my interest in it is not strong enough that I'd want to do much research on it. But as I might just not see the obvious, I'd like to know where exactly you see that team membership requirement being necessary to hold off cheaters from getting Gridcoins.

What happens with a user's Gridcoins if he leaves or is kicked from team Gridcoin? Does he lose them? Does he keep them but can't use them for anything anymore? If he keeps them and still can use them, the "damage" has already been done at the time the user is kicked.

Additionally, AFAIK, there's no way to prohibit a kicked team member joining the team again (it can only be closed for all not-members). Even if there was a way, the cheater might just create a new account.

The justification for holding onto the team membership requirement is purely for the ability to kick cheating users from the team.

What happens when an user is kicked from the team is that the Gridcoin client will detect they're no longer in the team & stop rewarding their CPID for the affected project. They would not lose previously fraudulently generated gridcoins that are held in their balance, so yes the damage is done (effectively cheating legit users out of their earnings).

You're right, there's no permanent ban option available; users can rejoin the team with their current CPID (to which we could kick them) or could create a new BOINC account to evade detection.

When an user's CPID is detected as invalid due to leaving the team, it'll be 24hrs before the next superblock can register their returned presence in the team, so if a cheater doesn't notice they may be prevented from earning rewards for days.

If cheating gets unmanageable, removing individual affected projects from the whitelist (ending distribution of gridcoin for work completed for a project) is a highly likely outcome.

Well, although the Gridcoin homepage says "The BOINC RAC system has existed for many years and has proven uncheatable.", it just hasn't. I've been BOINCing for more than ten years and I've seen more or less massive cheating going on all the time. Over the years, almost all projects were affected. Faked benchmarks on projects using the first, benchmark-based credit system, and the CreditNew lottery in recent days were only the tip of the iceberg. In at least one case, even the scientific results were compromised... and back then, there were only credits and badges, Gridcoins might be an additional incentive for some.

Yeah, that was admittedly an assumption on my part (I volunteered to create the website in my spare time; I'll change that part of the website tommorow.). I believe I've defended this point in the past too.. I have brought dishonour upon myself.

Why don't you remove the projects from the whitelist before the damage is done, i.e. removing all projects where cheating occured?

The damage done by a single project isn't significant - 26 projects & 50k Gridcoin per day = 1923 GRC per project. So say someone is faking 25% of an individual project's team RAC they're earning approx $4.80/day fraudulently.

We can vote to remove projects, those crunching projects may oppose the removal (by voting with their gridcoin balance). The removal of suspected affected projects from the whitelist is being heavily discussed in IRC.

I felt it was appropriate to create this discussion in order to discover how widespread cheating was/is & to delay mass removal of projects from the whitelist (heavy handed/nuclear action).

Somehow a picture crosses my mind that the people behind Gridcoin try to build an additional floor onto a house (BOINC), but while they know a lot about their building materials (cryptocurrencies), they don't yet understand the statics and the architecture of the house.

There's no company behind the development of Gridcoin, just a group of volunteers (from around the world) that have been arguing over the consensus mechanisms, reward mechanism calculations, how to store BOINC statistics on the blockchain, and more.

Sure a large quantity of Gridcoin users likely haven't gone through the BOINC documentation to thoroughly understand it, but I doubt the majority of everyday BOINC users have done the same either.

Maybe the lead dev knew about the limitations of the creditnew system (potential for cheating), but up until recently it's not been a significant problem (largely due to gridcoins not holding value until a year ago). The reward mechanism that has been created accurately reflects verified RAC on an individual BOINC project basis - if cheating is prevented/solved, it doesn't require much further development.

Either way, we're here now & we're dealing the ramifications live by reigniting credit system discussion & discussing internally how to react to cheaters without disrupting legit users' rewards.

The justification for holding onto the team membership requirement is purely for the ability to kick cheating users from the team.

[...]

When an user's CPID is detected as invalid due to leaving the team, it'll be 24hrs before the next superblock can register their returned presence in the team, so if a cheater doesn't notice they may be prevented from earning rewards for days.

OK, so it's basically the only straw you can catch until the lifeboats arrive. I understand.

Why don't you remove the projects from the whitelist before the damage is done, i.e. removing all projects where cheating occured?

The damage done by a single project isn't significant - 26 projects & 50k Gridcoin per day = 1923 GRC per project. So say someone is faking 25% of an individual project's team RAC they're earning approx $4.80/day fraudulently.

The damage done to Gridcoin might insignificant, but how about the damage done to the project and the BOINC platform as a whole? If a small project without lots of experience and manpower fails to react to cheating fast enough, it'll lose both the enthusiast crunchers (because they feel that the project is treating them unfairly and is not well-maintained) and the Gridcoiners (because they don't get Gridcoins anymore), leaving only a few participants really dedicated to that project. It's easy to lose credibility, but hard to get it back.

As soon as (again) someone finds a way to manipulate results in order to get more credit, projects might decide that distributed computing is not the way to go for them anymore. In more extreme cases, there might be bad publicity for BOINC. We already had someone distributing BOINC via a trojan. Also, a long-time top producer at SETI@home did run BOINC on school computers without permission (since he did not benefit financially, he was seen as a modern Robin Hood by some commentators... imagine the same story if he got money or Gridcoins for all that work).

I'm not saying that all of this will happen just because someone offers cryptocoins for credits (after all, my examples are from the past when there was no *coin). But if people are cheating when there are only funny points and badges at stake, why should they stop if there is additional incentive?

Somehow a picture crosses my mind that the people behind Gridcoin try to build an additional floor onto a house (BOINC), but while they know a lot about their building materials (cryptocurrencies), they don't yet understand the statics and the architecture of the house.

There's no company behind the development of Gridcoin, just a group of volunteers (from around the world) that have been arguing over the consensus mechanisms, reward mechanism calculations, how to store BOINC statistics on the blockchain, and more.

According to the points you mention, that group of volunteers appears to have discussed all the stuff that seems to be important for cryptocurrencies, but not that much about the problems and unwanted effects of it on BOINC. Exactly what I wanted to describe with my picture.

Sure a large quantity of Gridcoin users likely haven't gone through the BOINC documentation to thoroughly understand it, but I doubt the majority of everyday BOINC users have done the same either.

You're certainly right, and the majority (of all users including Gridcoin users) is also playing fair. The problems are caused by a small minority which understands BOINC well enough to know all the problems and use that knowledge for bad things. Anyone doing more than just crunching should understand BOINC and the influence of their actions on BOINC as good as that minority.

---

The problems are caused by a small minority

You just described the entirety of human history :P

---

My Detailed BOINC Stats

The justification for holding onto the team membership requirement is purely for the ability to kick cheating users from the team.

[...]

When an user's CPID is detected as invalid due to leaving the team, it'll be 24hrs before the next superblock can register their returned presence in the team, so if a cheater doesn't notice they may be prevented from earning rewards for days.

OK, so it's basically the only straw you can catch until the lifeboats arrive. I understand.

A more appropriate analogy:
Only the captain (team founder) of the ship (individual project's team gridcoin) is capable of reinforcing the slowly deteriorating leaky hull (Integrity of credit system) with wine corks (kicking users). Unfortunately, these corks only stay in place temporarily before shooting back into the ship; such efforts become less effective as new leaks become more difficult to detect as time progresses.

Currently, we've observed several spouts in multiple hulls and have approached the appropriate shipbuilders community for advice & begun discussions regarding how create more seaworthy hulls.

In the end, if any ships hull has become incapable of holding back the sea we can abandon ship (remove project from whitelist) and swim towards the nearest buoyant ship to utilize now untapped resources.

Why don't you remove the projects from the whitelist before the damage is done, i.e. removing all projects where cheating occured?

The damage done by a single project isn't significant - 26 projects & 50k Gridcoin per day = 1923 GRC per project. So say someone is faking 25% of an individual project's team RAC they're earning approx $4.80/day fraudulently.

The damage done to Gridcoin might insignificant, but how about the damage done to the project and the BOINC platform as a whole? If a small project without lots of experience and manpower fails to react to cheating fast enough, it'll lose both the enthusiast crunchers (because they feel that the project is treating them unfairly and is not well-maintained) and the Gridcoiners (because they don't get Gridcoins anymore), leaving only a few participants really dedicated to that project. It's easy to lose credibility, but hard to get it back.

As soon as (again) someone finds a way to manipulate results in order to get more credit, projects might decide that distributed computing is not the way to go for them anymore. In more extreme cases, there might be bad publicity for BOINC. We already had someone distributing BOINC via a trojan. Also, a long-time top producer at SETI@home did run BOINC on school computers without permission (since he did not benefit financially, he was seen as a modern Robin Hood by some commentators... imagine the same story if he got money or Gridcoins for all that work).

I'm not saying that all of this will happen just because someone offers cryptocoins for credits (after all, my examples are from the past when there was no *coin). But if people are cheating when there are only funny points and badges at stake, why should they stop if there is additional incentive?

You're right, the current generation credit system and cheaters could potentially be damaging the BOINC platform's reputation. That said, Gridcoin is not the root cause of cheating. There are several reasons (that have been around longer than Gridcoin) why users would want to cheat - charityengine, inter-team & inner-team competitions.

Any publicity is good publicity. If a BOINC cheating expose article hit the front page of reddit, there would likely be an influx of new users joining the BOINC platform. Our community hit the front page of reddit for a couple hours and we managed to recruit approx 1000 users in a single day to our team.

We don't need to wait for users to exploit a 4th gen credit system for your hypothetical scenario to apply - the issues exist with the current 3rd gen system, so projects may already be encountering cheating on a widespread scale causing them to consider alternative DC platforms.

There's no point worrying about BOINC projects shutting down - more projects will likely be created in the future to fill their place, and the benefits of free computing power from volunteers likely exceeds inconveniences caused by cheaters especially as we iron out how to make cheating less effective in this thread.

Somehow a picture crosses my mind that the people behind Gridcoin try to build an additional floor onto a house (BOINC), but while they know a lot about their building materials (cryptocurrencies), they don't yet understand the statics and the architecture of the house.

There's no company behind the development of Gridcoin, just a group of volunteers (from around the world) that have been arguing over the consensus mechanisms, reward mechanism calculations, how to store BOINC statistics on the blockchain, and more.

According to the points you mention, that group of volunteers appears to have discussed all the stuff that seems to be important for cryptocurrencies, but not that much about the problems and unwanted effects of it on BOINC. Exactly what I wanted to describe with my picture.

Discussing Gridcoin with communities outside of team 'Gridcoin' have largely been met with negative reactions - censorship on forums due to 'team-poaching' accusations, so the Gridcoin community has largely kept to itself up until now.

Up until Oct 2015, Gridcoin was a relatively small community & cryptocurrency issues took priority over BOINC development topics, now that the Gridcoin community has inflated in size more topics have become in scope - including this topic.

Gridcoin has not imposed new problems/issues onto the BOINC platform - the problems rising to the surface have existed for years now (with 0 discussion by the BOINC community nevermind the Gridcoin community). If it had not been Gridcoin, then CharityEngine or inter-team competitions would have exposed the same cheaters.

In the future, hopefully the Gridcoin and BOINC communities can work more closely together. Back on topic though, this is about BOINC's credit system not Gridcoin.

I welcome the new discussion on the BOINC Credit System and in particular how to identify and stop cheating. I am just an average user who after years of supporting BOINC projects have built up a farm of 10 computers (down 2). I am an avid competitor and watched users of similar equipment for years. I change my tactics to get an advantage for whatever the credit system is it should be equivalent for similar users of similar equipment. From time to time, I noticed a sudden jump in credit that in reality does not seem justifiable from a user that had a static average credit. Was he cheating? I do not know. What I do know is that he was hiding his hosts. Therefore, it makes it hard to prove and for this reason alone, I would suggest that the current option to hide your host be removed for it should be able to be seen by all and sudden unrealistic changes would be easier to identify.

Following the event of Bitcoin and high credits there has been a lot of talk about creating stats for various devisions in BOINC, not unlike the problems when GPU's and their higher credits came in existance some time ago. One that has not been mentioned as far as I am aware is the unfairness of organisations and IT professionals in control of multiple computers, yet they are included in the same category as an idividual user who pays for his equipment, time and Electricity out of his own pocket. Whilst I admit it is great to have such persons in one's team, I beleive in the individual scoring they should be given another category.

Keep on crunching and have a nice day...P.S Note that I have not edited my name but have changed it elswhere to my true name of peter J. Shane

It's worth keeping an eye on Storj https://storj.io/index.html to see how they figure out how to securely track storage and bandwidth usage. Currently they've got storage figured out, but not bandwidth.

Just found this thread on cosmology@home that's relevant to this topic: http://www.cosmologyathome.org/forum_thread.php?id=7341#20601

Sorry for my absence. Most of the things I wanted to write where already written by pschoefer. Thanks for that.

What I want to bring up again is what should Credits represent? It should be a measure for the Volunteer to compete with others, ok. With others in the same project? With others in other projects? With others who have the same kind of equipment?

Ensuring comparability among projects would mean that projects need to normalize Credit amongst each other. I don't think this is feasible. I like the Formula BOINC or Pentathlon approach better. If a project focuses on giving fair Credit to it's own volunteers and we don't directly compare Credit amongst projects the volunteer still has a good indication how good he is at specific projects.

For a fair Credit within a project it's important to decide on which value should we base Credit on. The "project-defined Credit" pschoefer suggested is a good approach but pushes complexity to the project where they want to focus on science not Credit. For a fair Credit within a project that has several apps it is important to grant fair Credit. So you probably can't use a fixed Credit approach with one app and CreditNew with another. All the previous Credit systems are based on runtime in one way or another and have this notion of an arbitrary standard (1000 Credits per Day on a 1GHz Pentium or something). This also means that projects need to supply an accurate estimate of how much FLOPs are needed to compute a workunit. If this estimate is off then runtime estimation is off, as is Credit calculation. Decoupling Runtime estimation and Credit calculation seems an obvious step as pschoefer already mentioned. Then the question is on what metric do we base Credit on if not runtime? Do we go back to the seticlassic days where we just counted successful tasks? Do we measure Credit by "Science" contained in a workunit (whatever that means)?

That's it for now.

P.S.: The author of the GeneralizedCredit proposal can be seen in the history of the wiki page.
P.S.: I don't know anything about the specific reasons why people hide their hosts but they should have the possibility.


Regards
Christian