Hi everyone! I just published a pre-print designing a new credit reward system for BOINC, which you can find here: https://www.researchgate.net/publication/357510448_Incentivizing_Energy_Efficiency_and_Carbon_Neutrality_in_Distributed_Computing_Via_Cryptocurrency_Mechanism_Design.

The goals of the reward mechanism are the same as the ones described by David Anderson in his paper giving an overview of BOINC (https://link.springer.com/content/pdf/10.1007/s10723-019-09497-9.pdf), which I've reproduced below for your convenience:

* be device neutral: similar jobs (in particular the instances of a replicated job) should get about the same credit regardless of the host and computing resource on which they are processed;

* be project neutral: a given device should get about the same credit per time regardless of which project it computes for;

* resist credit cheating: i.e. efforts to get credit for jobs without actually processing them.

The way that I've done this is by making an equivalence between the WUs of different applications. The summary of this method is that crunchers will be rewarded proportionally to their contributions as much as possible, and where they aren't rewarded proportionally, it's because their hardware is stronger/weaker on the applications that they are crunching.

Also, there is an anti-cheating mechanism described in Section 5, which overall reduces the amount of energy consumption/increases WU throughput of the network.

In Section 6 is a market system where crunchers can virtually trade their hardware with each other, which addresses the tradeoff between the applications that crunchers like the most, and the applications which would reward them the most.

I also take a look at ways that the computations can be made carbon-neutral, which I think is important given the impact that fossil fuel consumption and carbon emissions have on the environment.

If you notice any substantive mistakes in the paper, I'd be happy to update it and give you credit in the acknowledgments (I just found one typo myself, ironically in the word "acknowledgments" all the way at the end, hahaha). Also, implementations of some of the ideas in this paper will require work of various forms, including academic-level research, and I would be happy to collaborate with anyone who is interested. There are a number of open problems that people can also work on by themselves/in their own groups, if they wish.

While I did not evaluate the math in this paper, and I assume it is correct, I did read it thoroughly for the premise(s) and suggestions. I see several serious problems with it as it stands.

1) I may have misunderstood, but it seems like for this to work, every project would have to be running a "different" (newer) version of the BOINC server code. This won't happen. Many projects are using older (outdated) server code, for various reasons specific to their project. Others, notably WCG and LHC, run highly-customized versions. Obviously, any project choosing to do so would not be "in" the cryptocurrency-based system. There is no discussion of how "old" and "new" credit systems could work together.

2) "Credits" (cryptocurrency) awarded by a project would be set by a central process, not the individual projects. While the goal of having credits be equivalent/comparable between projects has long driven changes in BOINC, projects understandably resist any loss of their ability to set their own credit levels. Just for one example, PrimeGrid incentivizes running "unpopular" or project-preferred applications by granting a credit bonus % for those applications. PG overall is neither a "low-credit" nor "high-credit" project, and DOES attempt to grant credit "in-line" with other projects; however they still have valid reasons for not assigning "equal credit for equal effort" on their own applications. Other projects simply choose to give massive credits to draw participants. (The advisability of this is left as an exercise for the reader...) Likewise, the existing "anonymous" application platform would have to be eliminated.

3) There is repeated reference to changing the rewards for contributing based on (perhaps noble) societal goals. You mention both running BOINC preferentially during the winter months to reduce heating and air conditioning load, or running BOINC at "off-peak" hours for energy consumption. There are several problems with this;

a) You have to have a location for each machine. I'm not giving you that. Even for those willing to give you a location for their HOME, that does not mean all of their systems are in this location. Many of us run cloud instances that are not even on the same CONTINENT as our homes. I run "real" systems at three locations; you would need to track each machine individually, some of which are laptops which might move around the world... IP addresses would have to be tracked, and that is not reliable due to the use of VPNs.

b) Cloud instances in particular are minimally affected by the season outside - I would find it very difficult to believe that BOINC users have ANY effect on the amount of air conditioning consumed in any given AWS datacenter. Likewise they may be in widely varying time zones, and utilize electricity generated by widely varying fuel sources. Penalizing participants for running BOINC on a cloud server at a "undesirable" time or season is a non-starter.

c) The entire concept is based on there being wind/solar in the mix at all! A participant using nuclear energy should theoretically receive a HIGHER "clean bonus" than for wind/solar, one using coal a lower bonus, and yet both of these sources are constant, not dependent on either time of day or season. Plus there is the impossibility of knowing the energy source in use to begin with. At my home location, I can choose to buy energy from "clean" providers or from low-cost providers - even knowing my machine's location wouldn't tell you my energy source. I could also be "off grid" with my own batteries, which would be solar 24/7 - why would I be rewarded/penalized for running at noon vs. midnight? The current "reward/penalty" for running at the "wrong" time or season already exists (for many) - increased electric cost. Adding another level to this is impractical and unnecessary.

d) There is reference to rewarding the use for BOINC of "lower power consumption" CPUs and GPUs. I run both high-end Xeon servers and Amazon Fire Tablets (ARM) - obviously right now I receive a FAR higher return (in credits) for the high-end CPUs. The value to me of the low-end ARM devices is in WuProp hours, not Credits. My personal goals and BOINC project preferences are unrelated to credits in any event. If implemented, this would have the effect of lowering the number of high-end systems in use for BOINC - very counterproductive.

e) Some participants are not at all concerned with these "societal goals" to begin with - either because they do not directly pay for the electricity used (many people in apartments, or using cloud resources); because the amount used for BOINC is trivial in comparison to other uses; or because they have decided that they disagree with the goal. Incentivizing compliance with your chosen goals as an organization is fine, but BOINC is not an organization, but a collective of self-selected participants. Therefore DISincentivizing non-compliance by giving reduced rewards at certain selected times/seasons will get quite a backlash.

4) The centralized database of machines discussed is both in some ways a replication of the database held by WuProp, and at the same time a potential massive invasion of privacy (location), and a source for "cheating" that was not addressed. It is trivial for a participant to spoof the specifications of an individual machine - I could have my Ryzen 3600 tell BOINC that it was a Xeon or a Threadripper. There is also an existing flaw in BOINC that would have to be addressed, which is correctly reporting GPUs present when there is more than one.

5) There is a philosophical objection to the entire idea. You are paying people in cryptocurrency, transferrable to "real money" (or between participants - "credit trading?"), for participation in a volunteer computing system. MANY of us flat refuse to join/use/acknowledge GridCoin simply because they "pay" for service. We choose to use BOINC BECAUSE it does not "pay". If I wanted cryptocurrency, my systems would be mining, not running BOINC. If there was a cryptocurrency that contributed to distributed computing - fine. Those who wish to use it may do so. (ala GridCoin.) Changing BOINC into yet another cryptocurrency however will be fought against by MANY participants. If the goal of all of this is to increase the number of participants, where is the analysis of how many new people will join BOINC as opposed to just mining something else, and the analysis of how many of us would leave BOINC altogether? That seems far more important to me than analyzing ways of standardizing benchmarks, etc.

6) There is a PRACTICAL objection to the idea also. Every BOINC project and participant (again, unless I misunderstand the implementation) would be forced to move to a completely new build of server and client code, and potentially to new builds of every application as well. This is not a "new credit reward" system, it is a complete redesign and rework of BOINC from the ground up.

Hi! Thanks for your feedback :) You made some very good points, I'll try to address all of them.

1) I may have misunderstood, but it seems like for this to work, every project would have to be running a "different" (newer) version of the BOINC server code. This won't happen. Many projects are using older (outdated) server code, for various reasons specific to their project. Others, notably WCG and LHC, run highly-customized versions. Obviously, any project choosing to do so would not be "in" the cryptocurrency-based system. There is no discussion of how "old" and "new" credit systems could work together.

2) "Credits" (cryptocurrency) awarded by a project would be set by a central process, not the individual projects. While the goal of having credits be equivalent/comparable between projects has long driven changes in BOINC, projects understandably resist any loss of their ability to set their own credit levels. Just for one example, PrimeGrid incentivizes running "unpopular" or project-preferred applications by granting a credit bonus % for those applications. PG overall is neither a "low-credit" nor "high-credit" project, and DOES attempt to grant credit "in-line" with other projects; however they still have valid reasons for not assigning "equal credit for equal effort" on their own applications. Other projects simply choose to give massive credits to draw participants. (The advisability of this is left as an exercise for the reader...) Likewise, the existing "anonymous" application platform would have to be eliminated.

In Section 3, I describe an approach to approximating the rewards, which only requires a breakdown of WUs completed, by machine, by CPID, for every application. Every project already has this data available, they would just need to format it properly so that the data could be scraped. There is no obligation to do this - it's just than any project that doesn't consequently wouldn't be eligible for rewards. In fact, no project would have to change their credit-granting schemes at all, since it's the WU data, not the credits, that's actually needed. I probably should have made this clearer before posting here, but this isn't a reward mechanism that would have to be implemented within BOINC, this could be implemented externally.

3) There is repeated reference to changing the rewards for contributing based on (perhaps noble) societal goals. You mention both running BOINC preferentially during the winter months to reduce heating and air conditioning load, or running BOINC at "off-peak" hours for energy consumption. There are several problems with this;

a) You have to have a location for each machine. I'm not giving you that. Even for those willing to give you a location for their HOME, that does not mean all of their systems are in this location. Many of us run cloud instances that are not even on the same CONTINENT as our homes. I run "real" systems at three locations; you would need to track each machine individually, some of which are laptops which might move around the world... IP addresses would have to be tracked, and that is not reliable due to the use of VPNs.

b) Cloud instances in particular are minimally affected by the season outside - I would find it very difficult to believe that BOINC users have ANY effect on the amount of air conditioning consumed in any given AWS datacenter. Likewise they may be in widely varying time zones, and utilize electricity generated by widely varying fuel sources. Penalizing participants for running BOINC on a cloud server at a "undesirable" time or season is a non-starter.

c) The entire concept is based on there being wind/solar in the mix at all! A participant using nuclear energy should theoretically receive a HIGHER "clean bonus" than for wind/solar, one using coal a lower bonus, and yet both of these sources are constant, not dependent on either time of day or season. Plus there is the impossibility of knowing the energy source in use to begin with. At my home location, I can choose to buy energy from "clean" providers or from low-cost providers - even knowing my machine's location wouldn't tell you my energy source. I could also be "off grid" with my own batteries, which would be solar 24/7 - why would I be rewarded/penalized for running at noon vs. midnight? The current "reward/penalty" for running at the "wrong" time or season already exists (for many) - increased electric cost. Adding another level to this is impractical and unnecessary.

There are a lot of incorrect premises here. There are a few ways in which this reward mechanism incentivizes energy efficiency - the main one being that by construction, machines that are more efficient on particular applications will be incentivized to crunch those applications. Another is that the anti-cheating mechanism in Section 6 (which would only implemented on a voluntary basis) reduces replication of WUs substantially. A third is the market mechanism, where crunchers can voluntarily virtually "trade" their hardware with other crunchers. In no way, shape, or form would the reward mechanism know anything about where the energy sources are coming from - it at most only knows what I described earlier regarding WUs/machine/application data.

d) There is reference to rewarding the use for BOINC of "lower power consumption" CPUs and GPUs. I run both high-end Xeon servers and Amazon Fire Tablets (ARM) - obviously right now I receive a FAR higher return (in credits) for the high-end CPUs. The value to me of the low-end ARM devices is in WuProp hours, not Credits. My personal goals and BOINC project preferences are unrelated to credits in any event. If implemented, this would have the effect of lowering the number of high-end systems in use for BOINC - very counterproductive.

There is a bit of a misunderstanding here. I never referenced rewarding "'lower power consumption CPUs and GPUs". The reward mechanism has no knowledge of the type of hardware that's being used, or its energy consumption. The incentive is to use CPUs and GPUs in the most energy efficient way possible - that is, crunching the applications for with those CPUs and GPUs are most efficient. This is a natural consequence of the way that the reward mechanism is structured. The power consumption is irrelevant - what's relevant in the (WU output / power consumption) for each application. And even then, this is only an incentive, not a rule that crunchers would have to follow. Also, crunchers could virtually trade their hardware in a way that is beneficial to everyone involved in the trade by increasing the WU output of each application.

e) Some participants are not at all concerned with these "societal goals" to begin with - either because they do not directly pay for the electricity used (many people in apartments, or using cloud resources); because the amount used for BOINC is trivial in comparison to other uses; or because they have decided that they disagree with the goal. Incentivizing compliance with your chosen goals as an organization is fine, but BOINC is not an organization, but a collective of self-selected participants. Therefore DISincentivizing non-compliance by giving reduced rewards at certain selected times/seasons will get quite a backlash.

As I mentioned earlier, this reward mechanism could be external to BOINC. Also, it not the case that the reward mechanism would necessarily be "giving reduced rewards at certain selected times/seasons". In Section 2, I describe how giving a flat reward for WUs completed would do the exact opposite - a cruncher would receive the same rewards no matter when they crunched during the year. This is precisely why crunchers would be incentivized to run their hardware during the colder seasons where they are located - if they re-use the heat to heat their homes, then it will be cheaper overall to run their hardware during those months. They could still run their hardware whenever they want, and receive the same rewards, but running 100s or 1000s of Watts during the winter will pretty much always be cheaper than running it during the summer, barring some unusual circumstances.

4) The centralized database of machines discussed is both in some ways a replication of the database held by WuProp, and at the same time a potential massive invasion of privacy (location), and a source for "cheating" that was not addressed. It is trivial for a participant to spoof the specifications of an individual machine - I could have my Ryzen 3600 tell BOINC that it was a Xeon or a Threadripper. There is also an existing flaw in BOINC that would have to be addressed, which is correctly reporting GPUs present when there is more than one.

Assuming that you're talking about the database described in Section 4, it is similar to WUProp in some ways, but substantially different in that it runs benchmarks on the machine, rather than gathering data about that machine's performance on other BOINC projects. I'm not sure why you're mentioning an invasion of privacy via location - I never mentioned location at all. If you could clear that up, that would be great, I don't want there to be any confusion. Also, the specifications of the machines, spoofing their identities, and how many GPUs they have, are all irrelevant to the database, since it doesn't contain any of that information. There is in fact a problem with cheating in this approach, which I describe in detail in Section 4, but it has entirely to do with the fact that the benchmarks themselves can be faked, but nothing else about what you said. Also, this is only a second method to approximating the reward mechanism - the first approach is still there. It's just that this database approach has huge benefits both for BOINC and for researchers outside of BOINC, who could then be drawn into the fold.

5) There is a philosophical objection to the entire idea. You are paying people in cryptocurrency, transferrable to "real money" (or between participants - "credit trading?"), for participation in a volunteer computing system. MANY of us flat refuse to join/use/acknowledge GridCoin simply because they "pay" for service. We choose to use BOINC BECAUSE it does not "pay". If I wanted cryptocurrency, my systems would be mining, not running BOINC. If there was a cryptocurrency that contributed to distributed computing - fine. Those who wish to use it may do so. (ala GridCoin.) Changing BOINC into yet another cryptocurrency however will be fought against by MANY participants. If the goal of all of this is to increase the number of participants, where is the analysis of how many new people will join BOINC as opposed to just mining something else, and the analysis of how many of us would leave BOINC altogether? That seems far more important to me than analyzing ways of standardizing benchmarks, etc.

There are many people who cannot afford to run hardware for BOINC that would suddenly be able to do so if there was a large enough monetary compensation. As I mention in the conclusion, BOINC has a big problem in that it has stalled in growth - one of the purposes of this paper is to demonstrate how the massive increase in computing power and interest in cryptocurrencies could be redirected to running BOINC, rather than wasteful Proof-of-Work computations. This reward mechanism could be external to BOINC entirely, and so crunchers could voluntarily choose not to receive rewards for their contributions. In that case, pretty much nothing would change for crunchers who agree with your sentiments.

6) There is a PRACTICAL objection to the idea also. Every BOINC project and participant (again, unless I misunderstand the implementation) would be forced to move to a completely new build of server and client code, and potentially to new builds of every application as well. This is not a "new credit reward" system, it is a complete redesign and rework of BOINC from the ground up.

As I mentioned above, this is not at all the case for the approximation described in Section 3. The only data that would be needed are the WUs/machine/application statistics. Every project could maintain their current credit-granting system and it would have no effect on this reward mechanism, since it's based on WUs completed, rather than the credits given by projects. Any projects that didn't want to participate wouldn't have to - they could continue along as they currently do and pretty much nothing would change for them.

Thanks for the feedback, you raised some important points that I wish I had made clearer from the outset. I'm happy to answer any follow-ups you or anyone else might have.

If it’s external to BOINC, requires no changes on the part of the projects, it’s completely optional for crunchers, and pays those who choose to join… you’ve created a “better GridCoin” rather than a better credit system for BOINC, and I certainly have no objections. If you look at the BOINC Discord however, I think you’ll see several others with my same misconceptions/objections.

If it’s external to BOINC, requires no changes on the part of the projects, it’s completely optional for crunchers, and pays those who choose to join… you’ve created a “better GridCoin” rather than a better credit system for BOINC, and I certainly have no objections. If you look at the BOINC Discord however, I think you’ll see several others with my same misconceptions/objections.

Any projects that are interested in having their computations awarded could collaborate with the developers of the cryptocurrency - all they would need to do is format the data as I've described above. It seems like the two others that share your confusion also haven't read the paper. I will admit that some things that seemed obvious to me are definitely not obvious in general; I probably should have made clear that everything here is voluntary, both on the projects' sides and the crunchers' sides. I apologize for not making that clear from the outset.

If it has anything to do with cryptocurrency, any mention of it, or the word "Coin", then it's totally unacceptable when it comes to BOINC projects.
Crypto of any type, in my world is opening up for crimes over the borders of any country. Simply put No WAY I'd ever support anything like that.

All "crypto" should be made illegal in every country of the world (which it will, pretty soon now). Penalties should be life in prison. We have a working global monetary system already.

Basta!!

That is a very narrow-minded and dogmatic viewpoint. Many governments are actually looking into or in the process of adopting cryptocurrency either alongside their current fiat currency or as an electronic version. Not everyone in the cryptocurrency world is bad. Certainly not every use of cryptocurrency is illicit. I will point out that governments have no trouble tracking monetary flow through coins like Bitcoin, because the addressing scheme admits detailed tracing, in some instance better than fiat currency, because the monetary flows are all there for everyone to see.

Cryptocurrencies DO need to be regulated to some degree. This will all be sorted out in the next few years, but no, cryptocurrencies will not be outlawed.

---

If you want projects and the developers to notice this, I suggest you post this (with a link to this thread) to Github BOINC and the BOINC Projects email list. I did point it out to David Anderson but don't know if he will react.

Penalties should be life in prison.

You'll have to jail me too then, looking at my bitcoins that I am in the process of exchanging into different cryptos. Who will then remove the spammers?

Penalties should be life in prison.

You'll have to jail me too then, looking at my bitcoins that I am in the process of exchanging into different cryptos. Who will then remove the spammers?

I'm so sorry to hear that you're involved with the crypto scheme. It really saddens me to hear that. My deepest condolences.

I'm so sorry to hear that you're involved with the crypto scheme.

Well, consider this. I put in $1,000 and am walking away with $5,500. A friend of mine is investing my €400,- and will return to me €19,000 if all is well in a couple of months. How's that a scheme? It's just investing. It has a better return than my bank (0% interest).

That sounds more like inflation to me.

I started with boinc as volunteer user and i remain as one, but environment of would affect us all. If you join a project to cut some of the power or hardware it would be in same path as you or make an investment to it.
I support some currencies and used other to advantage others and also cut cost of use power i put into boinc of hardware and power.In my view it wide range of use and sure need to be regulated later on.

I do think we should drop crypto talk of this and focus on this thread for ILikeChocolate's post with suggestion as it include great info for changes that would be needed for boinc in general.

If you want projects and the developers to notice this, I suggest you post this (with a link to this thread) to Github BOINC and the BOINC Projects email list. I did point it out to David Anderson but don't know if he will react.

Thank you for this advice. I opted for a private e-mail instead for now, so as to not inflame any more passions. My only request is that people read the paper and make judgements based on its merits, and not on preconceived notions of what I must be suggesting. If you do end up reading it, thank you for taking the time, I really appreciate it :)