Flaws to creditnew

[47an]

This is an issue that have been brought up before team requirement lifted up.
here is a thread for that [Discussion] 4th Generation BOINC credit system

Here is boinc wiki for credit options: CreditOptions
Clarify credit options #2498 Clarify credit options #2498
and creditnew:
CreditNew

Old thread at LHC about this credits for runtime, not for cputime ?

I have post to project admins but no response yet that have shown flaws to those sub project that calculate by this design and abused.

It would open up to gain fullt credit of mt task with one thread only and on top of this run multiple instances to trick credit system.
Each host get high [Device peak FLOPS] counted and host could finish them and generate new hosts before corrections happen. The long runtime keep credits task high rewarded and does not care about cpu time.
Task and jobs would valid but project would have long list of burned hostid's in db with less work done.

As it looks now LHC and YAFU is affected by host that abuse this.

Which solution would be best if project can't or don't want to change it?
Should we greylist project as there is a flaws to system and give the project time to solve it?

from empirebuilder1 at discord chat #whitelisting-committee:

IMO it is not our position to "rule by proxy" over BOINC projects and dictate to them how to run their own credit systems. We can brainstorm and share ideas with them on their forums on our own individual bases of course, but GRC as a network should not get deep fingers into the project's nitty gritty and/or try to force the project devs to follow some given path.

Nor do I think it's a good idea to try and build mitigations into the GRC network to compensate for potentially faked tasks, whether temporary or permanent. That sounds like adding additional complexity for an edge case, and complexity brings unreliability, and unreliability brings even more gray hairs for Jim. We'd just be throwing bandaid fixes onto a problem someone else created, which doesn't solve the underlying issue of the chain of trust in the BOINC system being compromised. That has to be fixed on the project side.
(besides, from what I understand of how the GRC network interprets work data from projects, I don't think we have the granularity available to us to mitigate faked tasks in any way. Feel free to explain how I'm wrong though.)

Really I see our only option here is to point to our long-established security rules, say they aren't being met satisfactorily after the currently discovered holes, and then greylist until the project corrects their bugs, IF they correct the bugs. Those rules exist for a reason, and that is to set a standard for the chain of trust I mentioned earlier. It's entirely up to the projects to follow those rules, and if they don't, they get booted. Simple as that

[cyrossignol]

@47an Thanks for your research. In summary:

The LHC@home and YAFU projects can each be exploited to award credit unfairly for at least one of the sub-projects as a side effect of the "CreditNew" work estimation scheme. By manipulating a BOINC client host to throttle work units, a participant can earn much more credit than an honest contributor with the same hardware—and without producing a proportionate amount of useful output.

I reproduced this behavior as well. According to @47an in Discord, the administrators of both projects have not responded to a request for comments for two weeks. Since the fairness of credit distribution is fundamental to Gridcoin's purpose and protocols, I propose that the network immediately move these projects to the greylist until communication with the administrators proceeds.

[cyrossignol]

For the future, we need take a stance on CreditNew projects and decide if we should and how to examine credit fairness as part of the approval process.

[jamescowens]

I believe credit fairness is already included in the requirements for whitelisting. The two bullets of the whitelisting requirements...

• The project has a clear description of the work and the work is as described.
• All crunchers that comply with the terms of service of both BOINC and the project have equal access to work units

Implicitly cover the method of credit granting, because if the credit granting mechanism is cheatable, then bullet one is violated, and if people are able to rapidly consume work units without real work and rapidly accrue credit, it will also deny workunits to others and violate bullet two.

We should probably write some additional amplifiying information on this though.

I concur on the conclusion about the problem and agree these two projects should be greylisted. If the project administrators refuse to fix the issue I think we have to put the two projects up for a vote for removal from the whitelist.

[cyrossignol]

@jamescowens I think those implications are reasonable to support an argument for greylisting. From what I've read, a common-sense precedent also exists for past projects that failed to provide enough work to support fair credit distribution before the work availability guidelines were defined. I agree that the expectation needs to be more clearly expressed, though.

Sounds like a greylisting would be in place until the flaws on project side is solved. Maybe reach out to the project in a more official manner and and present the statistics of how big share of their crunchers that is motivated by Gridcoin. I don't believe that all gridcoiners will leave LHC if they was removed from the whitelist, but 40% of their BOINC computing power is hopefully not something they just ignore. Strength in numbers. If a last resort if they don't respond/act there should be polls for delisting.

[47an]

I been in contact admins at LHC and got reply that they think it is a general issue to boinc and should be changed on boinc level. They agree that there are host with abnormal credit and they will investigate more on it.

Both projects have taken actions to investigate or block users that would abuse this but they need help to change credit system or come up with better options to credit system from boinc server level.

So we can see that this an issue to boinc and we need another credit option for these type of projects as there are project that could be abused by this.
So we need to get together and reach out to boinc server github and bring this back alive or temporary greylist if they can't handle it another way.

It would be good if cpu time would be included to calculation to amount of credit generated but this open up for another issue that legit work have not been able to run fully and host have lost possible credit because general bugs in job/vm so for LHC it is more complex.

[jring-o]

I agree that these projects should be greylisted. I think that this should happen sooner rather than later.

[Pythonix]

I agree that the projects should be greylisted.

[47an]

If we interpret current system for greylist that it fall into this we have done what we can for now.

I will post last PM from Laurence from 12 Apr:

Thanks for the feedback. As a general comment, we use the BOINC credit system as is, so any issues/flaws should be raised against the BOINC software directly. Looking at the credit granted by Theory, ******* does seem to have an unusually high number of Theory results with large credit. However I also see one or two results from 'trusted users'. This could be an issue with the credit system wrt many core machines rather than cheating. Will continue to investigate but please let us know if you find anything else.

I did send PM back 18 Apr and ask for quick fix and and inform that project would be greylisted if there is no plan. No reply back yet after 3 days.

I would hereby propose that action is taken until they contact us here on github or project message board with solution. If they choose to PM me i provide info here.
Greylist for LHC could be lifted if there are any announced changes to project that could prevent abuse of credit system.

[RoboticMind]

So just as an update for those reading the thread, the two projects are now going to be put greylist on the next superblock.

See this post from Jim Owens on Discord

Looks like I will be greylisting both LHC and Yafu tomorrow. Very unfortunate but necessary.

[Dantali0n]

Unfortunately, I am doubtful that these issues will ever be addressed for LHC@home, seeing how this is almost the only project I use with BOINC, sadly this is likely farewell~

[Dantali0n]

The flaws in the credit system extend way beyond just the LHC@home and Yafu projects, see the discussion on the boinc mailing list:

https://groups.google.com/a/ssl.berkeley.edu/g/boinc_dev/c/ho3yDfktx10

[47an]

The flaws in the credit system extend way beyond just the LHC@home and Yafu projects, see the discussion on the boinc mailing list:

https://groups.google.com/a/ssl.berkeley.edu/g/boinc_dev/c/ho3yDfktx10

Thanks for sharing this post.
It it is good that projects reached out to question it and to found possible ways to deal with issue. There are ways but it would require a lot for project to work around creditnew as it is on default. They brought up another discussion and focus on gpus rather then big issue of mt/vm application which easy to trick fops/flops that determined the share of credit on each task.
Big issue is with these on two aspect of flaws and combine those it is open to gain more then 10X of credit for really no work done.
Not all project is open to abused same way as LHC and YAFU. It could be small profit but very low but could be changed if they make changes to how to calculate and applications.

I think you are right there is several project that use creditnew and it is set as default from boinc server on later versions and most used if project does not made any changes.
It may work well on native application that utilize hardware fully or close to it. Some project hold it it down to improve and ensure calculation is not throttle push co-processor to max and make inaccurate computing to unit. A wingman is good way to set to validate and should be used as default but more complex and reduced to only some host and unit to verify to cut it down and improve contribution on users asset.

BOINC is have work for long time and code behind is well done but can't adopt to complex changes to application to hold up credit system to all as it is. It would work on simple set to application and credit count are done to each batch before release but when they separate unit with real data jobs it opens up a gap of no real verify of jobs.
Wrapper is great to use and several projects use it but it does only fetch info they need as it is now but they can use ncputime as they say to take that into count of credit also. There is possible to improve and use basics info and use that in credit system also.

This issue was brought up at this point on projects because these have been proven to be abused heavily.
In this case i found one AMD 5900X That could create several instances of boinc and fake usage of mt task to and be valued more then 10x and able to hit top 5 at LHC. I also found out that throttled down in usage was not only factor of this and was open to users to extend runtime to be 200-260k instead normal 3-10k which increase and hold up credit as creditnew based of this.
If they generate new host each 2-4 days and only do 10-20 this creditnew does now get time to adjust credit and first task would be offset and grant 2x-3x what it should be on hardware used.
and project do make changes each year and with application version and batch to dataset.
I more for fixed credit if projects could handle flops/iops correct and to keep utilize cpu and gpu fully to cut down gap.

Scientific application is complex and hard to handle and optimize as it is and most project admins do not have background to code and would be more granting to science and make papers so they need to get help or learn. Sadly credit system is not highest priority into it so code to boinc server part is key to help them and leave great options for them to use for type application and dataset they use.
There is an improvement that need to be done and fall behind intime in focus of other things in code.

[47an]

I have done a lot of work to LHC and hope to continue to do so but greylist was necessary as it was heavily abused on several factors of flaws to credit system.
I this way most projects are not as easy to be abuse as LHC and YAFU but gpu applications do show show up to utilize enough on all high-end cards could do. This open up for users to extend usage by factors from 2X up to 10X.
on test to WCG i have reached 10X before hit full usage and would benefit many users to use to extend credit and contibution.
The use AutoDock and would use OpenCL 1.2 for both AMD and Nvidia cards and Intel. To compare to other scientific applications as GROMACS it still higher but dataset to unit could be better to allow to run several jobs to unit and to improve and increase contributions. As for now WCG is still on testing and they reduced credit by 50% data and applications are unchanged. This give more magnitude to cpu:s for now.