You are viewing a single comment's thread from:
RE: Current Problem with Rewards on Gridcoin and proposed solutions
I think both of these options are improvements on the current protocol.
However,
I think the ideal protocol would compare Flops volunteered by each user. This would eliminate the need to compare projects altogether: A user is rewarded in relation to the number of Flops they volunteer to BOINC instead of some ratio of RAC. I'm not sure how easy that would be to implement.
In the meanwhile, I think option 2 in this proposal holds the greatest long term potential.
I'm looking forward to this conversation = )
That would eliminate the reward for non computationally intensive projects :( We do not have any at the moment but hopefully some will come back in the future (looking at you @peppernrino).
good point. sc and cm also mentioned that it would require a new BOINC credit mechanism.
I think we need to decide what "THING" we want to give value to. Right now, that "THING" is proportional RAC across all projects. How is credit awarded to BOINC users? I mean, how does a project determine the value of a WU? And how would this translate to non-computationally intensive projects -- such as sensor projects?
With my current understanding, I think we should work toward rewarding the physical contribution toward a project. If it as a computationally intensive project, for example, we try to reward flops in proportion to other contributors. If it is non-computationally intensive, say it is a sensor project, maybe we reward the time the sensor is active along with flops contributed. I'm not sure, just rambling = ).
We probably want "research contributed" as our metric, which is what we do today with the RAC. What I don't like about the current setup is that there is a need to rush between projects in order to maximize profits. I would much rather see a system where you are rewarded more or less equally regardless of which project you choose. You can then pick the project you feel deserves your computing power without having to see your magnitude plummet just because of it.
I'm trying to think of a system where each project is given a slice of the total available magnitude based on how much it has progressed since the last superblock. Then that slice is divided to each of its members based on how much they contributed, kind of like how it would work if you had a pool of pools. The flaw I can't solve is how to determine how much a project has progressed. You can't just base it on percentual credit increase since that favors new projects.
Something along those lines at least. It's still broken but that's where I want to end up. In a world where you don't have to chase the smallest project in order to profit.
I don't think there is any way to find out how many Flops a certain user makes on a project. If we could , that would be a very good measurement.
For projects that are none computational, we could have two different ways of setting rewards, if they are computational or non-computational (WUProp was one for example).
I hope you mean the flops contributed and not the boinc specs of the host. Otherwise it's only a matter of creating hosts and doing/contributing nothing. And what about iops?
yes, flops contributed
FLOPS contributed being the defining metric will skew research entirely towards only GPUs being profitable.