P.S.: I don't know anything about the specific reasons why people hide their hosts but they should have the possibility.

Regards
Christian

My suggestion would be to allow Team Founders to see this data anyway, keep the average person from seeing it, but if you join a Team then the Team Founder CAN see it, after all it's THEIR Team that's being affected by the cheating. People used to hop from team to team when team total credit went with them, when that stopped some of the team hopping stopped, but some people still hop from team to team for various reasons. If someone is cheating and viewing their pc's can help stop that and allowing Team Founders to see all Team Members pc's can stop it, then I'm all for it. But as I said if you have 50 pc's because you are running a computer lab or whatever and wish to keep them hidden from the general user, I'm okay with that too.

P.S.: I don't know anything about the specific reasons why people hide their hosts but they should have the possibility.


Regards
Christian

100% agree. I have very specific reasons that are important to me as to why I choose that option. One is that it helps cut down on the shenanigans that go on during challenges. I'm sure many of you know about the crap that happens during the annual large challenge with projects that require a "wingman." JMHO

Seems to me there is a need to start with basics.

If a particular Boinc project has a financial reward then it should develop whatever payout system that works for that particular project.

Expecting projects that were never conceived as for profit to consider adopting another credit system to accommodate for profit projects shows quite a bit of arrogance in my opinion.

I am utterly uninterested in any possible side effect this has for GridCoin. As GridCoin is a profit-seeking venture, the BOINC credit system has no responsibility, ethically or morally, to change its system(s) to suit the needs of GridCoin.

I was compiling a list of projects and figured it'd be interesting to scan the SSL certificates of all (most) BOINC projects.

Projects with F/T gradings or no SSL support at all need to step their game up ASAP.

... and if they don't, what exactly will happen?

If you really want to be helpful, post it in each forum.

I used letsencrypt on my own website & received an A+ rating. It was free and took an hour max to setup. https://letsencrypt.org/

Ah yes they have been in the news lately. Misuse of letsencrypt

When you say no SSL support what exactly do you mean, as i know at least one of these does support SSL as i know it. I suggest you check again.

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.

Since the creation of gridcoin 3 years ago, every time I've attempted to mention it on individual BOINC team forums users have reacted negatively due to the team membership requirement and instead of joining the discussion about gridcoin and proposing a change of this policy I'd instead just get banned from their forums for 'attempted team poaching' and they shun the project entirely.

Every time someone has come to my team's forums "educating" us on the latest crypto combining DC scheme (which many of my team members mined bitcoin), the initial "promotion" was presented with a "hey look at this great way to get paid to do what you are already doing...(you just have to switch teams)". When you go to a team forum and say look how great it would be to switch teams...that isn't just being informative. That is poaching. My teams forums actually split crypto out of the DC section so that it would easily address this issue and would prevent those against monetary gain in DC attacking those looking for a few $$. What those in the crypto for DC camp typically miss is that they are coming from a different culture of things. Their mindset is a bit different. Many people take pride in what they are doing and actually have loyalty to their team. Offering them a gamble of making a few $$ if they switch teams may be enticing to some, but it is offensive to many others. And yes it is a gamble as it is not much different than the cryptos before in its volatility. At least not yet. Quite frankly, Gridcoin needs BOINC or another popular DC. The DC community does not "need" crypto. It is a nice perk, but forcing people to switch teams to get that perk typically doesn't go over well in another teams forums. Just my $.02 USD.

Edit: Oh, and we typically did propose to remove the team change requirement. We just weren't going to go find your forums to discuss it as the topic was brought to us. Gridcoins offer to pay people is too small of an incentive to make it worth many peoples time to register an account and argue with people that are just as one sided as the other side is.

Notice a similar post from 2014 https://hardforum.com/threads/folding-protiens.1831468/#post-1041060486 in regards to CureCoin which was a folding@home crypto. They were one of the only ones actually trying to find a solution to the teams problem at that time. As far as I know they never came up with a good solution that didn't require giving them keys to your castle...

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.

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

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.

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 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

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.

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

For some reason, the other thread has been locked (hopefully this thread will not meet a similar fate)

All threads auto-lock after 90 days to stop spammers from using them as their vessel to sell their crap. Yours will fare the same fate, unless you or others periodically add content to it.

Clicking on the (report post image) on the locked thread and requesting that a moderator opens the thread so you can add to it is also a possibility. As long as you then add content to it within the next 24 hours, else it'll auto-lock again.

It is quite apparent to me that this project is run by an amateur who is in way over his head. I encourage everyone to drop this project immediately, as the admin can't even be bothered to provide any sort of explanation. This project does not deserve any support from the BOINC community and should be dropped from everyone's list of active projects.