Polling adjustments

[Weber462]

https://www.reddit.com/r/gridcoin/comments/z0bh56/poll_rule_change_discussionpoll/

The 40% AVW requirement is limiting progress: Polls with overwhelming popularity will and do fail.

Crunchers should have the right to NOT actively contribute to the community: Currently If you decided not to contribute by voting, it will act against those in the community trying to make advancements. There might be crunchers that do not check wallet, don't care about polls, or just prefer not to be actively involved, they SHOULD HAVE THAT RIGHT, but not at the cost of others.

I would propose at minimum 20% AVW (from 40% AVW in most polls) across ALL polls. Also, I would like a condition that states "Any position that reaches 90% or more on any poll after specified duration will be adopted, and the poll will be considered VALID."

[jamescowens]

I am not in favor of creating a 90% or more voting on any poll as a loophole.

These are the current numbers. const std::vector Poll::POLL_TYPE_RULES = { // These must be kept in the order that corresponds to the PollType enum. // { min duration, min vote percent AVW, { vector of required additional fieldnames } } { 0, 0, {} }, // PollType::UNKNOWN // Note that any poll type that has a min vote percent AVW requirement must // also require the weight type of BALANCE_AND_MAGNITUDE, so therefore the // only poll type that can actually use BALANCE is SURVEY. All other WeightTypes are deprecated. { 7, 0, {} }, // PollType::SURVEY { 21, 40, { "project_name", "project_url" } }, // PollType::PROJECT { 42, 50, {} }, // PollType::DEVELOPMENT { 21, 20, {} }, // PollType::GOVERNANCE { 21, 40, {} }, // PollType::MARKETING { 21, 40, {} }, // PollType::OUTREACH { 21, 10, {} } // PollType::COMMUNITY }; Just thinking carefully about this, this how I think we should adjust the AVW % numbers:

Project 40 -> 20 Development 50 -> 25 Governance 20 -> 15 (I don't think we should cut this in half, lest people question whether we are creating a very low bar loophole.) Marketing 40 -> 20 Outreach 40 -> 20 Community 10 -> 10 (unchanged) The AMA outreach poll would have passed using 20% for Marketing poll type.

[Weber462]

Agreed. I also believe voting AVW will also rise as people become accustomed to voting and it’s process. I saw questions posted on Reddit about how to vote from headless server. I think people are getting more involved. I agree with the cuts listed above. The last few polls show that they are reachable.

[Weber462]

What’s difference between governance and development? And I didn’t see governance at all on website. And under what poll type would this change fall under? Governance I assume? Edit: Governance is labeled management and is listed. (sorry, I didn't see)

[iFoggz]

Yes the AVW are not neccessarily the greatest. When it comes to development polls I believe that this should remain high as this affects the network in whole (both non-crunchers/crunchers).

In the past I thought of why non-crunchers should have any weight on a whitelisting poll. The listing of a project does not affect a non-cruncher as they collect CBR and tx fees.

I always thought a CPID Magnitude should equal the weight of a vote for a cruncher towards a whiteliting poll however this brings up a whole slew of more issues to try to combat.

Such as:

• Is there a minimum CPID Age to be eligible to vote for a whitelisting poll to prevent someone making a bunch of CPIDs to exploit the one vote per cpid situation.
• Should the vote of a CPID be considered as a single vote during the voting period and eliminate balance?
• • if so when the poll ends should the average of the magnitude of each cpid over the length of the poll period be the ending vote weight for the poll with regards to the cpid who voted?
• • if so do we take the network_max_magnitude_average for the period of the poll and subtract the average magnitude for the pools during that period and use that as the total_network_votable_magnitude? and figure of the AVW based on the magnitude_averages_of_all_cpids / total_network_votable_magnitude_average to get a %.

Just some old idea in a text file I had from years ago thou its incredibly complex on how to do that.

I wonder how polls would of panned out that way.

For example the current AVW% for folding at home poll is 24.94% of the required 40% (includes balance and magnitude)

For example if doing what I've said above consider the magnitude of a cpid instead keeping in mind that it is not averaged the current magnitude total that has voted is 26036 and the current sum of pool magnitudes is 13039.1. so 115000 - 13039.1 = 101960.9. so 26036.13 / 101960.9 = 25.5%

Often I wonder if a bunch of crunchers do not vote as they do not believe the low balance and magnitude would have much impact. Whereas a low magnitude alone without balance would be heavier in weight in the end if the non-cruncher whales were not involved in the vote.

Anyway don't really have much say or suggestions on this topic thou I agree some voting weight %s could be voted on for change. we have multiple choice polls for that reason.

[jamescowens]

We cannot use "vote by CPID" either, because while it is more difficult to create multiple CPIDs that correspond to one unique person, this can be done, and therefore this type of counting is prone to Sybil attacks and cannot be used. The same rule of linearity to prevent the possibility of Sybil attacks applies for magnitude as well as balance.

[jamescowens]

I have considered all of the comments and we need to put modified AVW % validation points up for a vote.

The general gist is that my suggestions above were ok with folks, except that development should not be halved. Here is my proposal for the new AVW percentages required to validate each poll type. As a reminder, the current poll validation parameters:	Poll Type	Minimum Duration (Days)	Old Minimum Active Vote Weight (AVW) %	New Minimum Active Vote Weight (AVW) %
Survey	7	NA	NA
Project Listing	21	40	20
Protocol Development	42	50	35
Governance	21	20	15
Marketing	21	40	20
Outreach	21	40	20
Community	21	10	10

I am going to put up a poll for the community to approve these. This poll, because the AVW %'s do not affect consensus code in the wallet currently (only the display of the "validated" badge), is properly a governance type. The minimum durations are consensus enforced and would require a protocol change, but these are being left alone. Note that the current poll to whitelist folding@home passes with the new project listing AVW % proposed. I am going to have this governance poll finish before the folding@home poll, and if this governance poll passes, it will be in force prior to the completion of the folding@home poll, which means the new AVW % for project listing will apply, 20%.

[jamescowens]

See https://www.reddit.com/r/gridcoin/comments/zq7pgh/governance_poll_to_change_poll_active_vote_weight/.

[empirebuilder1]

Damn, I was losing my mind doing finals and forgot to chime in on this official discussion.
I will copypaste the message I sent in the Discord in relation to changing AVW for discussion completeness. The new numbers @jamescowens has put out into the poll are still a little more conservative in a couple areas than I would like, but I think they are going to be ultimately acceptable for future growth and will vote yes on the poll.

My original Discord message:

As the network has grown, vote participation drops, that's a natural effect of having a greater number of actors that are less invested in the entire network. A small decrease in AVW% would make sense. But I don't think a complete halving is necessary though. The adapter poll passed 20% in only a few short days in a very long poll...

Generally the AVW% is meant to guide the "severity" of a poll, so that those polls that have wider reaching effects on the network as a whole (dev, whitelist) require higher network participation to approve than those that are mostly perfunctory (marketing, outreach).

To this end I would support the following changes with explanation:

Project 40 -> 30 Adding new projects is quintessential to GRC's growth as a network, a slight lowering of the AVW requirement would make sense as most users currently crunching have lower coin weights (and thus are most affected by this poll, NOT balance whales that crunch little) and would like to see new projects to crunch added so they may get a better mag share. Lowering this requirement makes it easier, and more attractive, for projects to join. In the end, adding a project to the whitelist is obviously not permanent if they don't pan out.

Development 50 (unchanged) These are rare, and fundamentally change the function of the ENTIRE GRC NETWORK. A majority consensus about fundamental protocol changes is still absolutely necessary IMO to maintain faith in continued active development. It has already been proven that, with some concentrated outreach, we can get to 50%AVW where it matters, and as such this should remain the same for the time being.

Governance 20 -> 25 I feel 20% may actually be too low for deciding funding directives as well as poll requirements. Seeing as how 20%AVW is still not a difficult bar to pass currently, 25% feels more reasonable. Obviously increasing any AVW is probably unpopular currently, so in lieu of, just leave it unchanged.

Marketing 40 -> 20 Outreach 40 -> 20 Lowering both Marketing and Outreach makes sense at this point in the game. They could even be merged into a single type. We are well established with a solid userbase, and marketing campaigns are not "sink or swim". We don't need a huge network consensus to tell us that an advertising campaign is good or not, and many users probably do not feel strongly one way or another about it and may just not vote.

Community 10 -> 10 (unchanged) Low priority, 10% is fine for things that do not affect the network of course.

I bolded the section on development polls because this is the point I want to make the most. I still don't agree with lowering the requirement for development polls with widereaching effects on the network below 50%, or even 40% at the absolute extreme. Requiring a true majority network quorum for things that inherently affect the entire network maintains a much stronger layer of confidence and trust in the development process that ensures the network truly agrees with the chosen path. Not that I don't trust our amazing devs, nor have development polls ever been terribly close, but my personal opinion is it retains trust both internally and externally.

[parnikkapore]

Judging by the AVW turnout for the last couple of polls, I am leery about adjusting Governance / Management below 30%, and definitely not below 20%. I agree with empirebuilder that this type of poll passing could lead to widespread, major effects. (straw man: removing all AVW and duration requirements, then subsequently getting a very harmful and widely considered unacceptable Development poll passed)

But again, this being set at 20% originally might hint at something I am not seeing.

[div72]

Voting no. I especially agree with @empirebuilder1 for the development change and the governance change.

I'd like to remind folks AVW is active vote-weight. Lowering the requirements isn't ignoring lost coins or some wallets running in forgotten VPSs, it's ignoring the action of inaction from people who are actively maintaining their wallets(at least up to mandatory releases).

The staking but not voting people are most likely only a few whales with large balances, so this feels like a wrong solution(lowering the AVW thresholds) to a wrong problem(voter turnout) to me.

[jamescowens]

That is why there is a vote. Not everyone has to agree, even on the core team.

[jamescowens]

I actually don't think it is a wrong solution. No one has offered a better one that passes tests such as Sybil attack immunity, etc. for a quorum standard. Setting a slightly lower threshold for these means that some of the whales that are actively staking do not have to participate. The proposed thresholds are high enough to be representative of the community for the poll types as indicated.

[Weber462]

“The staking but not voting people are most likely only a few whales with large balances” This is the problem. A few whales can control all voting just by doing nothing. And if avw is lowered this is resolved, correct? I’m sure I missing something. I feel like when 90% (over 400 votes) vote for something, it should pass.

[jamescowens]

Exactly.

[div72]

I actually don't think it is a wrong solution. No one has offered a better one that passes tests such as Sybil attack immunity, etc. for a quorum standard. Setting a slightly lower threshold for these means that some of the whales that are actively staking do not have to participate. The proposed thresholds are high enough to be representative of the community for the poll types as indicated.

Listing a few things from top of my mind that could've been done to increase voter turnout/poll visibility before making this poll:

• Overview page shows only the newest poll even when it's voted on and there are older polls which weren't voted on.
• Loading the polls should not take more than 3 seconds.
• I remember CallMeFoxie mentioning CLI users do not have any easy way of getting notified for polls. A -pollnotify option(maybe even making it mandatory with -alertnotify to be set for daemon users.) could be nice.
• Investors could be not counted for AVW for whitelisting polls since mostly crunchers are affected for them. (Unsure on the logistics on this one without introducing anti-privacy features. Also would probably need a separate poll.)

“The staking but not voting people are most likely only a few whales with large balances” This is the problem. A few whales can control all voting just by doing nothing. And if avw is lowered this is resolved, correct? I’m sure I missing something. I feel like when 90% (over 400 votes) vote for something, it should pass.

That sounds to me like the problem is not related with the voter turnout but with the wealth distribution.

[Weber462]

All Of those points seem valid. Maybe we can make polls to fix those? It will be easier to make adjustments if this is passed. I feel like Wealth distribution is not an issue. Some people just dont want to play an active role. That is their choice. Why should progress be decided by those who choose not to be involved? It seems very counterproductive.

[div72]

Why should progress be decided by those who choose not to be involved?

There's an option for that. Abstain. Not voting is the fourth option for a Yes/No/Abstain poll.

The proposed thresholds are high enough to be representative of the community for the poll types as indicated.

Surely not for protocol polls.

[Weber462]

You can’t force people to abstain, you can’t force people to vote. You can’t force people to pay attention. Progress should not be dependent on those who do not participate.

[Weber462]

Look at currently F@H vote. 450 votes. Only 1.5% no. 95% yes. And it will most likely fail. Does a No vote represent the community?

[div72]

How do you propose we have mandatory releases then? At least 51% of the network needs to pay attention in order for the mandatory to remain the main chain.

Also, hypothetically you could encourage voting or discourage not-voting monetary-wise.

[div72]

Look at currently F@H vote. 450 votes. Only 1.5% no. 95% yes. And it will most likely fail. Does a No vote represent the community?

I'd say there's a special case for whitelisting polls as I mentioned earlier. Other polls effect the whole network but whitelisting polls only effect the crunchers while having the fulfill the same criteria for the AVW as the other polls.

[div72]

There's also a case I've been wondering, voting essentially ties all your balance and CPID. Could any whales have privacy concerns against voting?

[jamescowens]

There is really no expectation of privacy on the Gridcoin blockchain, and quite frankly that hasn't stopped the whales from voting before. Note all of the whales vote, but enough of them have in the past.

As to the 51%... you are forgetting that at the end of the day, the final vote of a mandatory is installation of the new version to implement the protocol changes by the fork point. Our last mandatory change, the MRC vote, we barely made the cutoff, and this was for a change that had been asked for by the community for years. This represented the active staking coins, and yet, when the mandatory came and went, the difficulty on the network is higher than ever, which indicates that just about all nodes that count upgraded.

[jamescowens]

The protocol development standard simply needs to be high enough to ensure it is not a rogue, but not so high as to serve as an impediment to the forward progress of the coin.

[jamescowens]

On your comments...

• Overview page shows only the newest poll even when it's voted on and there are older polls which weren't voted on.

Yes. The logic could be changed now that we include the concept of IsMine on the poll tally, and now store whether the wallet has actually voted already on a poll. This is a good idea.

• Loading the polls should not take more than 3 seconds.

This will require splitting loading the poll "envelope" from the poll results, which is done in the RPC already via listpolls, but not in the GUI. Quite a bit of GUI rework here. To see useful information about the vote tally beyond just a listing of the polls requires the full tally be done, which is expensive.

I am looking right now at the locking stuctures. Cycy puts the the poll refresh in a separate thread:

`void PollTableModel::refresh() { if (!m_model || !m_refresh_mutex.tryLock()) { return; }

QtConcurrent::run([this]() {
    static_cast<PollTableDataModel*>(m_data_model.get())
        ->reload(m_model->buildPollTable(m_filter_flags));

    m_refresh_mutex.unlock();
});

} `

However, farther in it takes a big lock on cs_main during the entire tally for ALL of the polls. We have to redo the locking approach for this. I am working on that right now.

` std::vector VotingModel::buildPollTable(const PollFilterFlag flags) const { std::vector items;

LOCK(cs_main);

for (const auto& iter : m_registry.Polls().Where(flags)) {
    if (std::optional<PollItem> item = BuildPollItem(iter)) {
        items.push_back(std::move(*item));
    }
}

return items;

} `

• I remember CallMeFoxie mentioning CLI users do not have any easy way of getting notified for polls. A -pollnotify option(maybe even making it mandatory with -alertnotify to be set for daemon users.) could be nice.

This is a good idea.

• Investors could be not counted for AVW for whitelisting polls since mostly crunchers are affected for them. (Unsure on the logistics on this one without introducing anti-privacy features. Also would probably need a separate poll.)

I am nervous about that.

[Weber462]

I have asked community about a way to notify crunchers of polls and updates (an opt-in email notification). Delta will create a project.

[jamescowens]

I saw that. Good idea.

[barton2526]

Should this be closed?

[jamescowens]

Yep.