-
Notifications
You must be signed in to change notification settings - Fork 1
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bounty: 5k GRC -> fair rewarding: GREYLISTING of whitelisted BOINC projects #6
Comments
Jamezz spoke about creating a draft version of a grey-list whitepaper in the 22nd hangout. |
cc @grcjamezz |
Thank you Erkan , since we apparently moved to bi-weekly mumbles this will give me plenty of time to write up a bit cleaner than a verbal rough draft of the concept and original idea I had along with incorporating the ideas contributed by other community members ideas all merged together along with a forum to discuss and draw up more than an idea or concept but hopefully the active mechanisms that will need to be in place both soft and hardware wise. I plan to submit a topic request for " grey list white paper read off " for the next session on the 4th of Feb 2017 and present it in the mumble first then post here. If anybody wishes to communicate via mumble or irc collaborating please feel free to contact me , ideas always welcome that may benefit the community as a whole. |
i think a greylist system is a great idea and addition to the whitelist. Projects can run into problems or issues and a greylist could give them a certain time period to correct these issues before even a poll would be considered for removal and would solve the whole jump to a removal poll. Perhaps maybe a greylist could temporarily block the coins for that project after a certain time point after no activity and spread them across other projects until it has moved back into the whitelist. Yes peoples RAC/MAG will suffer during the greylist period but its not like any work is being done for the project to begin with. gridcoin is rewarded for work and it seems whitelisted projects that run idle are just easy payouts. just thought i would add my thoughts. cheers. |
mentioned in hangout 26: making a bounty for this task |
The fair rewarding is also connected to:
|
like the new title its an easier pill to swallow in a way. fair would make users unfamiliar with various subjects more accepting of the idea. |
When I mentioned the original idea it would do this #1 watch white listed projects for availiable work track and at 60 days #2 put the project in a jailed state thus the rac/mag was paused and the project was given 30 days to figure out their complications or #3 be auto removed from the whitelist. I will use for example drug discovery , since we know they are going away I would consider right now its on the grey list... We have RAC/MAG and credit but no new WU till off the WL. If we automate the system and even put new projects on the same system so to be a trial into the gridcoin blockchain reward system if they tank in 90 days its automatic. Also 30 days should be long enough for users to move from a project with no WU to a new project and not effect their hard work to get to where they are with gridcoin. So I thought the gridoin team req could be used to seperate the users stats when on the 60-90 days jailed stats system ( this also would mean if someone had a system off with completed WU and sent them they would not get credit unless durring the 60-90 day period the project produced work units ). I assume , no I know people will say a stat pause system for that 30 day period would be unfair. BUT i want to mention that lots of users dedicate themselves to 1 project trusting that if they are on boincstats/gridcoinwhitelist even a server they really is no different that apache for httpd , openssl for ssh , its a generic server with a generic front end with BOINC and BERKELEY's name all over it but Gridcoin is the best checks and balance for the BOINC system and its a bonus , you can earn a percentage of what you put in and its not 1:1 its more like 1:100 and its dynamic and we are a community make it's value. Situations where say a project is voted into the WL tanks within 6 months and you have not been rewarded for all work done due to internal issues and its voted out you never recieve that reward. Currently there is no work for a week and its on a list and 3 days latter the vote ends. This would make it asyncronus vs dynamic times/rules creating a non byist WL because someone doesnt agree with a project not having openssl or they just dont crunch it or even just see NO is the majority vote or YES and follow the majority. This creates fairness for all aspects of the internal " honored " system vs crunchers whom have been in #gridcoin for years vs the new ones in the past year , and the new ones that are just learning solo vs pool and even what the projects are about being " guided " by the trustedd #gridcoin community leaders like @Erkan-Yilmaz @grctest and @Peppernrino along with the trusted help's options. We can also chart and keep track of these things most likely with netdata style loggin and tracking for work and projects over time for both historical and a good chart for new users joining leaning what works best on their hardware. Sorry but I've only had my 2nd cup of coffee and its a saturday so laying in bed as I type this , I had not submited anything due to #gridcoin constant political and micro political bullshit. I doubt any this will be in the final project but here is some of the original idea. Thanks , take care. - Jamezz |
Time to get this done.. I'm somewhat of a bystander as I don't have the relevant skillset but there is an urgent need as highlighted by the recent DD@home debacle. |
yes this would be nice to have. idk if itd just be simular to whitelist but have it rewardless? remove project from whitelist to greylist list through simular means (i havent looked at much of that process yet). a move project feature? saving time in removal and addition between lists? just throwing ideas out there. we should brainstorm on this for sure. idk if adding an extra field on projects to say wheater its whitelisted or greylisted would be easy or not. |
Consider using total credit information from exported stats instead of RAC. Then the NN could compute magnitude based on the difference between last 2 superblocks. Also: https://github.com/gridcoin/Gridcoin-Research/wiki/DEV-Neural-Network |
Port the Neural Network to Linux first? In case the porting involves rewriting no work would be lost. |
We could scrape server_stats.xml for each project for data to base the grey-list on. Example xml file: http://moowrap.net/server_status.php?xml=1
The above could be used to monitor the state of each BOINC project's server component, which could differentiate between a lack of WUs and a broken server. The problem with monitoring each of these server components is that they are unique for each project, some have the default implementation where as other such as SETI have like 20 custom components. Perhaps a basic monitoring, or monitoring for 'failure/error' would be useful?
The contents in the above should be the primary focus of a grey listing mechanism. Specifically the following fields within the 'database_file_states' section:
NOTE: Some projects do not offer server_status.xml extracts which can be scraped, so some compatibility would be broken unless we could pressure said projects into creating these files. Server_status xml links:
|
I pledge 5k GRC for this cause, to give the "bounty" at least a number |
example to comment 292554904 above: In the current #933104 superblock are only 2 of the 25 whitelisted projects (so, 92% missing). and the situation seems like this:
or in current monetary terms:
|
status on projects for last 7 days:
|
a very, quick explanation of this, from IRC: user1: i am not understand this all with the "greylistings"
user1: in boinc max bunker volume are 5 + 5 days
|
This is now completed, I put together a proposal that was accepted and is now in operation. |
I add 2000 GRC on this and a fair share of used contribution used to code on this. |
I agree that we now have a greylist. Thought when I pledged my part of the bounty, I thought about an automated system in the code. It first crossed my mind to split the bounty for the current greylist and the new, automated greylist. But that is too complicated. So I think at least my bounty should go to the creators of the current system including the website(s?) That is displaying the greylist. :) |
Quezaciatk1 , that seems to be debatable and honestly I personally think that payment for what currently exists does not qualify for what was intended when a bounty was created. I fully agree as I intended it to be automated vs editing a .php website manually. I consider the project not accomplished or under " not at the level of quality expected by the community " and it should not be accepted as completed. |
I´m up for make it automated before close. thanks for post jamezz, i would like to see what you have in your mind to contribute to make this complete. |
I do not agree that @G-UK put as little effort as possible into his whitelist website. |
fair rewarding is important, otherwise some users get magnitude without doing anything/much.
fediverse and gridcoinstats already detect when projects have no WU, in progress WUs
but Gridcoin itself doesn't :-(
mentioned in hangout 1: 0:23:45
The text was updated successfully, but these errors were encountered: