Below is an introduction to a proposal followed by the proposal itself. There will be a two week discussion period before the proposal is put to a poll. Thanks to @barton26 and name831 for helping proofread!
Introduction
Gridcoin polls are a tool that help guide decision-making on the Gridcoin network. It is difficult to use this tool without clear polling definitions and validation parameters. This will become increasingly difficult as we continue to grow and decentralize as a network and community.
I propose defining requirements and validation parameters for polls. To do this I propose defining seven types of polls with appropriate requirements and parameters for each. I propose this split because a major protocol change, for example, is much different than a minor marketing proposal and should be held to a different standard. Additionally, a protocol change and a marketing initiative, for example, are going to have different aspects to their proposals. Lastly, the new GUI assets have the potential to set a poll type when making a poll. This will help organize polls in the client so participants can more easily see what is happening.
I am looking for feedback, concerns, questions, and suggestions during this discussion period. I think a particular focus should be put on AVW validation parameters and required poll times. As this is a fairly significant proposal, I think it is appropriate to use the poll time we decide on for this proposal as a standard across other major polls.
Please comment on the steemit or reddit threads, or reach out on slack or discord. Thank you!
Timeline of this proposal
Introduction and preliminary discussions on slack: Already done
Presentation to the larger community: Now
Discussion period: 2 weeks - Ends March 6th
Poll: 2-6 weeks depending on the discussion
Notes on discussions and decisions:
Below are some notes based on the preliminary discussions that took place on slack.
On AVW validation values
Several weeks ago we spent some time discussing possible AVW values on slack in the #poll-definitions channel. The values in this proposal represent the outcome of those discussions.
AVW was introduced with the CBR poll. Since then I have been following as many polls as I can taking note of the AVW before and after whales enter their votes. It seems as though all major polls have breached 100% AVW (super-validation). Major polls without significant whale participation seem to break 30% AVW. Major polls with limited whale participation seem to break 60% AVW. We are going to need to continue to observe poll results as we get deeper into the CBR economy as CBR has stabilized the network difficulty at a higher level than under the APR model.
If anyone wants to break things down into real data, please do! All the information is in the blockchain and there are several explorers that might help break it all down. I used https://gridcoinstats.eu.
The goal with this proposal as it stands is to get things moving by setting AVW values and implementing a process to change these values in the future. A management poll is that process. Management polls are set at 30% AVW so they will be validated with relative ease. This should force us to have a conversation and make a decision when a change is proposed.
The two week discussion period on this proposal will hopefully give us time to discuss this concept and these values as a community before putting it to a poll.
On the extent of this proposal
The goal with this proposal as it stands is to get things moving by defining poll-types and requirements/validation parameters. We could poll each poll-type individually, however I believe that this will consume a significant amount of time with minimal return when compared to defining a foundation for all poll-types at once. We have much to do and since polls play a significant foundational role in guiding our decisions, I think we should get this over with as quickly as practically possible so long as there is a reasonable way to change things in the future.
On Outreach
Outreach in this proposal is seen as:
Legitimizing community representation - If someone and their proposal (documentation, presentation, talking points, etc) is voted as a representative at a specific event they can say they represent the network. If not, they are an individual that is part of the network.
Compiling, building, and maintaining proactive documentation - Shared presentation material, for example.
Maintaining channels of communication for those outside of the network and community - Contact with BOINC projects and exchanges, for example.
Allocating resources to take advantage of opportunities as they present themselves - cross-community partnerships, for example.
On unvalidated polls
If a poll is unvalidated it is not considered actionable. This means that the proposal would need to be reworked, ideally through collaboration, and presented again. This encourages collaboration and discussion from the start which in turn helps ensure quality proposals.
On flaws with AVW
They exist and I believe there are solutions. I also believe AVW is a better metric than TVW. I detail this in the proposal. For now, I think the most important thing is to get these requirements and parameters defined so we can move forward with other developments. This proposal defines a process by which we can tweak the system as we grow.
____________________ START ____________________
1.0 Voting
Gridcoin utilizes a protocol based voting mechanism to:
- Gauge interest
- Inform development and organizational direction
- Utilize foundation funds
Any network participant with a balance of 100k GRC in a wallet can create a poll. A poll must meet all requirements for the appropriate poll type to be considered valid.
There are seven types of polls.
1.1 Vote Weight and Active Vote Weight
Vote-weight is the power given to a vote cast on the Gridcoin blockchain. It is measured as a modified sum of balance and magnitude. The formula for vote-weight is:
VoterBalance+VoterMagnitude((TotalMoneySupply/TotalNetworkMagnitude)/5.67)Total vote-weight (TVW) is the total possible vote-weight of the network. It is calculated as a weighted sum of total minted coins and network magnitude. The formula for total vote-weight is:
TotalMoneySupply+TotalNetworkMagnitude((TotalMoneySupply/TotalNetworkMagnitude)/5.67)Active vote-weight (AVW) is a calculated average of the coin weight actively securing the network for the duration of the poll, plus the network magnitude, less the magnitude of any crunching pools. The formula for AVW is:
AV-W = (Average Difficulty* 9544371.769) + ((TotalNetworkMagntiude- Average Pool Magnitude)* (Average MoneySupply/TotalNetworkMagnitude)/5.67)AVW as a metric solves the validation problems of total vote-weight validation, including missing vote-weight due to lost and burned coins, coins in cold storage, coins held by exchanges, and vote-weight frozen by crunching pools.
AVW enables high weight validation via active network participants.
AVW enables super-validation. Super-validation is a validation percentage greater than 100%. Super-validation implies that inactive balances were brought online to vote on the proposal in question.
Note: TotalNetworkMagnitude = 115,000
1.2 Poll Validation by Active Vote Weight
Poll validation requirements are intended to ensure no proposal passes without significant network support. Each poll type has its own AVW validation parameter initially defined in this proposal. Validation parameters can be changed through management polls.
If a poll is not validated no action is taken.
1.3 Requesting Funds in Polls
Any proposal requesting reimbursement or funding from the foundation must be approved by a network poll.
Funding can be requested for all poll types except for Opinion/Casual and Whitelist polls. The following information is required if funding is requested in a proposal.
- Intended use of funds
- The date of work begin
- The date of work end
- Total funding requested (denoted in GRC)
- When funds are released
- How funds are released
- The payee's name or alias
- The payee's wallet address
- Reliable contact information
1.4 Poll Types, Requirements, and Validation Parameters
There are seven poll types. All poll types except for Opinion/Casual must use "Magnitude and Balance" as weight metrics.
1. Opinion/Casual
Opinion/Casual polls are for early exploration of ideas or for fun.
Examples
- Do you support the continued exploration of this CBR idea?
- Do you support the continued exploration of this protocol change idea?
- Masternodes, DPoS, PoS, or PoW?
- Cubes or curds?
Poll Requirements
NONE
Validation Parameters
NONE
2. Development
Development polls include polls to change a protocol value or for proposing changes to the protocol at large.
Examples
- Implement CBR as proposed?
- What should the CBR value be at implementation?
- Remove the BOINC team requirement?
- What should the side-staking development requirement be at implementation?
- Implement MRC as defined in this proposal?
- Change CBR value to 3.1415?
- Change development side-stake requirement to 2%
Development Poll Requirements
- Main Poll Discussion Thread on Github or Reddit
- Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread
- Minimum 6 weeks (42 day) Poll Time
- Unbiased Poll Phrasing and Options
- "Abstain" Vote Option
Development Poll Validation Parameter
- AVW of 60% or greater
3. Marketing
Marketing polls include any proposal for marketing initiatives.
Examples
- Do you support this proposal for taking out an ad in New Scientist magazine?
Marketing Poll Requirements
- Main Poll Discussion Thread on Github or Reddit
- Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread
- Minimum 6 weeks (42 Day) Poll Time
- Unbiased Poll Phrasing and Options
- "Abstain" Vote Option
Marketing Poll Validation Parameter
- AVW of 50% or greater
4. Outreach
Outreach polls include any proposal which seeks to:
- Legitimize community representation
- Compile, build, or maintain proactive documentation
- Maintain channels of communication for those outside of the network and community
- Allocate resources to or otherwise take advantage of outreach opportunities as they present themselves
Examples
- Do you support representation at [Conference A] as detailed in this proposal?
Outreach Poll Requirements
- Main Poll Discussion Thread on Github or Reddit
- Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread
- Minimum 6 weeks (42 Day) Poll Time
- Unbiased Poll Phrasing and Options
- "Abstain" Vote Option
Outreach Poll Validation Parameter
- AVW of 50% or greater
5. Management
Management polls include any proposal which seeks to modify the management or organizational structure of Gridcoin.
Examples
- Do you support the proposed management proposal?
- Change AVW validation parameter for development proposals to 50%?
- Change minimum required poll time for Outreach polls to 4 weeks?
Management Poll Requirements
- Main Poll Discussion Thread on Github or Reddit
- Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread
- Minimum 6 weeks (42 Day) Poll Time
- Unbiased Poll Phrasing and Options
- "Abstain" Vote Option
Management Poll Validation Parameter
- AVW of 30% or greater
6. Community
Community polls include any proposal or initiative related to the Gridcoin community, but unrelated to any other department.
Examples
- Do you support this community competition?
- Do you support hosting this crunching competition?
Community Poll Requirements
- Main Poll Discussion Thread on Github or Reddit
- Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread
- Minimum 2 weeks (14 Day) Poll Time
- Unbiased Poll Phrasing and Options
- "Abstain" Vote Option
Community Poll Validation Parameter
- AVW of 30% or greater
7. Whitelist
A whitelist poll is used to add or remove a project from the whitelist. The whitelist is a larger mechanism within the operation of Gridcoin. Each project considered for whitelisting must meet a set of requirements, and several actions must be taken before a poll for adding or removing a project can be considered valid. A project can be removed from the whitelist at the discretion of the whitelist admin if it ever fails to meet a requirement described below.
More information including discussion threads that informed the creation of the whitelisting and greylisting processes, information about each project's Work Availability Score and Zero Credit Days, and details on the greylist process are linked at the end of this section.
Project Requirements for Whitelist Consideration
- Project Work Availability Score is green
- Number of Zero Credit Days is less than or equal to 7 out of the last 20 days
- The project has a clear description of the work and the work is as described
- The project allows new user registration
- Project complies with the BOINC terms of service
- All crunchers that comply with the terms of service of both BOINC and the project have equal access to work units
Required Actions before Creation of Project Addition Poll
- Direct contact with a project administrator
- An affirmative public response to whitelisting by a project administrator
- An agreed add date with both the Gridcoin whitelist administrator and project admin
Required Actions before Creation of Project Removal Poll
These are necessary only if a project meets all whitelist requirements, is not greylisted, and is otherwise functioning as intended
- A public attempt at contact with a project admin is made
Examples
- Add project SETI@Home to the whitelist?
- Remove project SETI@Home from the whitelist?
Whitelist Poll Requirements
- Main Poll Discussion Thread on Github or Reddit
- Secondary discussion threads on Github, Reddit, and Steemit with links to each in each thread
- Minimum 2 weeks (14 Day) Poll Time
- Poll Options:
- Yes
- No
- Abstain
Whitelist Poll Validation Parameter
- AVW of 50% or greater
https://gridcoin.ddns.net/pages/project-list-process.php
https://github.com/gridcoin-community/Gridcoin-Tasks/issues/194
https://github.com/gridcoin-community/Gridcoin-Tasks/issues/213
https://github.com/gridcoin-community/Gridcoin-Tasks/issues/201
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.
Green on their server_status page, or on the greylist websites?
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).
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:
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..
Thanks for putting all this together. It's on my to-do list now to go through the points in more depth and give my thoughts.
Should be coin weight, not vote weight.
AVW is the total voting weight on the network which is, when boiled down, coin weight + magnitude magnitude weight. I might be missing something but I think it's vote weight.
The full quote is:
I'm pretty sure you just confirmed what I was saying.
Ahhh got ya. Fixed.