Delegating recent average credit to another account

[grctest]

Describe the problem

As an user I wish to give my recent average credit (RAC) to another user without having to use their account, I'm currently unable to do so with my own account.

I'm able to provide RAC to another account if they provide me a weak authenticator key to do so, however this has several drawbacks:

• You must communicate directly with the account holder, requesting they provide you the weak authenticator.
• If the target account is non responsive to your communication efforts then you cannot contribute your compute power nor RAC to their account.
• The specifications of my computer may be exposed to the target account holder, I may be unable to hide my computer details unlike when I use my own account.
• My existing active RAC cannot be transferred, it may take up to a month for the full RAC contribution to be recorded by using their weak authenticator to contribute to their RAC. Meanwhile my RAC will slowly drain to 0 as I no longer contribute to my own account anymore.
• If I no longer want to share my compute by no longer using their weak authenticator, my own RAC starts from 0 rather than the full RAC.

Describe the solution you'd like

Introduce a new field to the profile page where the user can specify another BOINC user's account to receive your full RAC.

Possibly also add a button to other user's profiles (not your profile) as a shortcut to delegate RAC to this profile's account.

If the user has provided an account in this field, then set the user's RAC to 0, then contribute the RAC to the target account.

Don't include the donator user's computer in the target user's host machine list.

Additional context

Total credit is not in scope, recent average credit only.

If target users are earning money for charity then you could contribute to their efforts by delegating your RAC to them, instead of involving yourself at all in 3rd party reward systems/mechanisms.

This issue proposes delegating 100% of your RAC to a single account account for simplicity sake, however it could be split among multiple target accounts. The weak authenticator cannot be used to contribute 25% to 4 different accounts with the one BOINC client, however it sounds feasible simply splitting the delegated RAC among multiple accounts.

[davidpanderson]

Is this a BOINC issue? AFAIK BOINC has no mechanism for transferring credit between accounts.

[grctest]

I selected the 'feature request' option when creating this issue for the BOINC web server, yeah.

You're right that there isn't a mechanism to transfer RAC, the closest thing to it right now is using another account's weak authenticator to add your pc to their account per individual project.

I'm interested in trying to figure out the feasibility of this idea, whether it'd slow down (or complicate) credit calculations too much, or if there could be a minimum viable method for users to donate their RAC to others?

Perhaps the simplest change would be to check if the user has populated the new profile field, and if so grant the credit to the target user and their team instead of my account's within the grant_credit.php and credit.cpp files? Are there other files I should look into too? Thanks

[CyberTailor]

BOINC Credit should not be a subject of trade, it's not a currency.

[grctest]

Thanks for the input @CyberTailor, however I don't believe this would constitute a form of a trade system being introduced.

Trade implies the donator account would get something in return for their donation, which they wouldn't; the donation receiving account wouldn't even be alerted to this 3rd party contribution nor would the target account be shown in the donator's public profile page.

Rather, it's a proposal to introduce a one way charitable donation mechanism from one BOINC account to another BOINC account within a single project, with no goods of any kind returning back to the donator.

There are other reasons for this other than boosting the 3rd party earning potential for the receiving account:

• Donating RAC to your friend's account so their leader board rankings improve
• Donating RAC to another team without leaving your own team and without alerting your own team that you're doing so, without having to create a secondary account.
• Avoiding use of weak authenticator for this same purpose
• Avoiding disclosure of compute host details to the 3rd party account you want to donate RAC to (compared to weak authenticator usage)
• To possibly avoid taking credit for important distributed computing discoveries, maintaining ones anonymity and granting another the right to claim 'ownership' of the discovery.
• To take part in BOINC compute competitions/marathons without joining a team.
• Using an unique email address & password combination for each project to maximize cross-project operational security, avoiding use of a merged CPID, then donating said RAC to another account which does have a merged CPID.
• To maintain the BOINC contributions for an account which nobody has access to anymore.
• As a means of rejecting credit reward entirely for my volunteer efforts
  • Why broadcast that you've got say 8x 4090s to the world when you could instead fully fly under the radar whilst maintaining your legitimate distributed computing contributions? Reduces the odds of your account being targeted to be compromised.
  • Also, if you plan on (or already are) writing off your BOINC contributions as a charitable tax contribution (where possible), by further donating your credit to another it further supports its charitable status to tax authorities. I suppose this would arguably be a trade off, but very much so an edge case.

Further, in my follow-up message I have already proposed reducing the scope to simply changing who receives the new credit on work unit completion, rather than messing around with already rewarded credit - your existing RAC would deplete to 0 like swapping to using their weak authenticator would.

This reduced scope idea wouldn't transfer existing RAC nor total credit, it would simply contribute new credit to an existing RAC upon the completion of work units, so it'd still take approx 30 days to have full effect.

[davidpanderson]

The purpose of credit accounting is to know how much work was done by each computer. Credit-shuffling would undermine this, so we're not going to add such features to BOINC.

[grctest]

Fair enough, understood, though I always thought the purpose of granting credit was primarily that of gamification, encouraging more people to legitimately compete crunching more work units faster than one another, rather than just for establishing benchmarks for unique host machines, wuprop has that pretty much fully covered for most hardware combinations.

I wouldn't have thought that project owners would have cared much whose accounts RAC is being legitimately distributed to, considering their bottom line is the more work units being legitimately solved the merrier?

I was thinking that if you delegated to another, then it wouldn't check their account for nested delegations, preventing loops or nested credit delegations, so with that limitation it'd be less of a credit shuffle and more sliding my credit into your account...? lol

Thanks anyways for all the input on the idea, much appreciated. I might try implementing this anyways in a forked repo of my own for projects to implement at their own discretion.