You are viewing a single comment's thread from:

RE: Pre-poll Discussion: Poll Definitions

in #gridcoin6 years ago

One downside of AVW which stands out is that lower POS difficulty lowers the AVW which could encourage whales to not stake or for parties to dos staking nodes to lower AVW. During hardfork/mandatory upgrades this AVW might be an unstable value.

Perhaps instead of 'TotalMoneySupply' in TVW, a more appropriate value could be the the sum of coins on addresses with coin-age less than a year? That would take destroyed coins and deep-cold-storage coins out of the equation.


Project Work Availability Score is green

Green on their server_status page, or on the greylist websites?

A public attempt at contact with a project admin is made

I'm not 100% on board with this, with the team-req still in place it's very easy to trigger flamewars/drama if you're making a public plea to 'do/change x or lose whitelist status' people can get rightfully defensive at an outsider making ultimatums. I got banned from bitcoin utopia for asking them to implement SSL for example.

Perhaps the onus to reach out to projects for whitelist retention is on those interested in keeping the project on the whitelist? Rather than the person proposing the poll, who'd be probably biased towards whitelist removal.

IMO you aught to have the right to throw any project to whitelist poll for any reason, if it fails to meet the min reqs then would go nowhere as per the poll definitions, right? It shouldn't be solely reserved for when there is some major incompatibility (like mandatory new features).

Sort:  

WRT observations: I see the same. Maybe we should look into some solutions to these. Something like freezing AVW at the start of a poll for that poll. For the time being I think AVW still provides a better metric than TVW because...

I think that AVW already does what you suggest we do with TVW. AVW ignores all destroyed coins and coins in cold storage. It also ignores coins and magnitude in the pool (which cannot vote on the blockchain). Could be mistaken.


Green WAS on whatever is closest to reality and practical. I'm not sure on the difference between server_status page or greylist site data.


When removing a project from the whitelist, it makes sense to me that there is an attempt to contact the admin so they have the opportunity to present their case or fix any issues. A project removal proposal that doesn't do this should be invalid for a few reasons, two major being:

  1. At least trying to reach out is just a nice thing to do
  2. It presents a barrier to entry for polls -- I, the user, can now ignore any old poll about removing a project unless it demonstrates that it is following the steps (responsibility and commitment). This sort of thing will probably come in handy down the road.

Regarding onus: Generally belongs to the actor and not recipient. In context, we're talking about the act of proposing whitelist removal, not retention. If someone is going to seriously poll to remove a project, they should reach out first, if only to let them know.

I'm not sure how ultimatums to BOINC projects or flame-wars relate to this proposal. I think you might be talking about the problems of representation and outreach/contact, which have solutions tangent to this proposal, but I'm not sure.

Could you explain more on how this proposal limits the rights of someone to make a poll? That's definitely not the intent.

Wasting your time on a dead project , shitty coin ran by Nazi dictators? Again trying to change shit. Gridcoin's leadership is a circle jerk with plenty lube and kneepad's for the leadership, you know, that place you asserted yourself since day 1. Gridcoin need's to be be revamped and Nazi mentality. If a leader forced on us wants to emo quit or anger quit fuck him. Also poll and whitelist + greylist what a failed shit show. Also thanks for the dos/ddos idea cm-steem since we need the centralized main node.gridcoin.us it might like packets thrown at it..