This proposal is like sweeping the good and the bad together under the rug. I think we can do better.
1 Like
This 0.5% can’t get anything passed. They have to have at least 3% understand it enough to vote yes. I agree that things were better before and I think we should revert to all proposals being valued the same. I think it is the only way to not have to create an overcomplicated system.
This proposal just creates a threshold that something that can’t get 3% shouldn’t figure into rewards at all. Take away the hiding aspect of the proposal and consider just the suggestion to not figure any proposal that can’t get at least 3% to count toward rewards. That is no different than the old system and just makes sure that you can ignore trash proposals and not vote on them as opposed to voting no.
I can amend the proposal as such. See below:
Motion to restrict rewards qualification to a threshhold
Objectives:
Decrease incentives to submit spam governance proposals
Protect the NNS from censorship, and preserve the current accessibility of submitting NNS governance proposals (i.e. does not increase the cost or difficulty of submitting an NNS proposal).
Allow NNS voters to ignore spam
Note : In this post, all references to “proposal” refer to all proposals, those could be restricted to governance proposals, but I don’t think that is necessary.
Solution
Update the NNS canister to skip rewarding proposals that have not received at least the Minimum threshold of Yes votes required to pass threshold of Yes votes(currently 3%).
Update the NNS canister to extend the end date to match the initial voting period when the proposal passes threshold of Yes votes required to pass Yes vote proposal.
Implementation for Proposed Solution
After line 6027( https://github.com/dfinity/ic/blob/79bbd3177f6532037eb29d62b3e52a364a8103ee/rs/nns/governance/src/governance.rs#L6027 ) add the equivalent Rust code to the pseudocode below:
if( proposal.tally.yes/proposal.tally.total < MIN_NUMBER_VOTES_FOR_PROPOSAL_RATIO){continue;}
After line 5274(ic/governance.rs at 35acac6c1113a23e2cb92329f1431c5254567e6e · dfinity/ic · GitHub) add the equivalent Rust code to the pseudo code below:
let oldYesRatio = proposal.tally.yes / proposal.tally.total;
After line 5284(ic/governance.rs at 35acac6c1113a23e2cb92329f1431c5254567e6e · dfinity/ic · GitHub) add the equivalent Rust code to the pseudo code below:
if (proposal.tally.yes / proposal.tally.total >= {MIN_YES_THRESHOLD} and oldYesRatio < {MIN_YES_THRESHOLD}){proposal.deadline_timestamp_seconds = deadline_timestamp_seconds + (now() - proposal.proposal_time_stamp_seonds);
This proposal is put forward to complement https://forum.dfinity.org/t/proposal-introduce-an-incubation-period-and-minimum-support-threshold-for-governance-proposals/12220/14 which is a longer-term solution. This implementation could be created much more quickly.
Accept: To vote Yes (Accept) means you agree that the above code changes should be made.
Reject: To vote No (Reject) means you do not agree that the changes should be made."}}; neuron_id_or_subaccount=opt variant {NeuronId=record {id=12008772471346176261:nat64}}})'
1 Like
But can you do better by only changing 4 lines of code 
1 Like
If I can get general agreement that we should not reward proposals that cannot reach the 3% threshold ofaccept votes I’ll tear down the proposal to remove anything about the UI except a recommendation that is a NNS UI providers offer a filter similar to the hide votes I’ve already voted on filter that is in the NNS now. This will read something like add a filter to “hide any proposals that have not reached a reward threshold.” It will be 100% up to the user to decide to turn this on or off.
Here is the amended language:
Motion to restrict rewards qualification to a threshold
Objectives:
Decrease incentives to submit spam governance proposals
Protect the NNS from censorship, and preserve the current accessibility of submitting NNS governance proposals (i.e. does not increase the cost or difficulty of submitting an NNS proposal).
Allow NNS voters to ignore spam
Note: In this post, all references to “proposal” refer to all proposals, not just governance propsals.
Solution
This solution only requires the editing of 3 lines of code.
Update the NNS canister to skip rewarding proposals that have not received at least the Minimum threshold of Yes votes required to pass the threshold of Yes votes(currently 3%).
Example:
Proposal A: Final tally 2% of the total voting power to accept, 45% of total voting power reject - Proposer is charged a fee and the proposal is NOT considered for rewards.
Proposal B: Final tally 4% of total voting power to accept, 45% of the total voting power to reject - Proposer is charged a fee and the proposal IS considered for rewards.
Proposal C: Final tally 40% of total voting power to accept, 10% of the total voting power to reject - Proposer is NOT charged a fee and the proposal IS considered for rewards.
Proposal D: Final tally 2% of total voting power to accept, 1% of total voting power to reject - Proposer IS charged the reject fee and the proposal is NOT considered for rewards. Proposal is rejected as it is today.
Update the NNS canister to extend the end date to match the initial voting period when the proposal passes the threshold of Yes votes required to pass the proposal.
Example. If a 4-day proposal passes the 3% yes on the 3rd day, it will be extended for 3 more days so that gets the original 4 days of exposure to the broadest set of voters.
Implementation of Proposed Solution
After line 6027( ic/governance.rs at 79bbd3177f6532037eb29d62b3e52a364a8103ee · dfinity/ic · GitHub ) add the equivalent Rust code to the pseudocode below:
if( proposal.tally.yes/proposal.tally.total < MIN_NUMBER_VOTES_FOR_PROPOSAL_RATIO){continue;}
After line 5274(ic/governance.rs at 35acac6c1113a23e2cb92329f1431c5254567e6e · dfinity/ic · GitHub) add the equivalent Rust code to the pseudo code below:
let oldYesRatio = proposal.tally.yes / proposal.tally.total;
After line 5284(ic/governance.rs at 35acac6c1113a23e2cb92329f1431c5254567e6e · dfinity/ic · GitHub) add the equivalent Rust code to the pseudo code below:
if (proposal.tally.yes / proposal.tally.total >= {MIN_YES_THRESHOLD} and oldYesRatio < {MIN_YES_THRESHOLD}){proposal.deadline_timestamp_seconds = deadline_timestamp_seconds + (now() - proposal.proposal_time_stamp_seonds);
This proposal is put forward to complement [Proposal] Introduce an incubation period and minimum support threshold for governance proposals - #14 by justmythoughts which is a longer-term solution. This implementation could be created much more quickly.
Implementation Note: Unsuccessful proposals will still be charged the reject fee even if the proposal is not included in reward calculations
Recommendation
This proposal also recommends, but does not require that NNS frontends implement a filter to “Only show proposals that have met the reward threshold.” This filter should be off by default and only selected at the user’s discretion.
Voting
Accept: To vote Yes (Accept) means you agree that the above code changes should be made.
Reject: To vote No (Reject) means you do not agree that the changes should be made."}}; neuron_id_or_subaccount=opt variant {NeuronId=record {id=12008772471346176261:nat64}}})’
Expected Outcome: There will be less incentive to submit spam/inappropriate proposals as it they will be unlikely to hit a 3% accept threshold without the significant organization of an attacking party of 3% of the NNS voting power.
1 Like
Is there the tacit agreement that, if less than 3% vote on this, it will be nullified?
This would centralize the nns. If no one is rewarded for voting on new proposals unless they reach 3% yes, then most people will not want to vote on them or see them and it would be way harder almost impossible for someone who isn’t so well known to pass a proposal.
If less than 3% got on any proposal it is nullified even if it has more yes votes. I’ll add that scenario as an example.
Sure, later I can abstain. My question is whether this course of action will have an impact in this proposal, since the proposal is not yet passed
Hi @skilesare, thanks for writing this idea up! I have one main concern wrt this proposal.
I think right now people pretty unanimously vote no on spam proposals, because they’ll get the increased rewards anyway, and additionally the 10 ICP of the proposer will be burned if they reject. With your proposed change, the voters are now actually incentivized to vote yes on spam proposals, because if it reaches at least 3% yes, they will get boosted rewards. So I expect that many will vote with their own financial gains in mind, and that therefore all spam proposals will reach 3% yes, and the change you proposed will not have any effect.
5 Likes
@skilesare my opinion is similar to @Manu. I think this proposal won’t work unless the incentive to ignore, abstain, or not vote yes is decoupled from financial gain that is offered by voting yes.
2 Likes
Hmmm…perhaps you are right, but also maybe you underestimate human cruelty. 
First I’ll say that this proposal isn’t independent of other solutions. Provided other solutions solve incentive problem, do you think this helps solves the “pay for publicity” problem for people that turn on the filter?
Second, It is an interesting question about incentives. Given the opportunity to reward my self immorally or punish someone else financially for bad behavior, what will people choose? I think it probably varies with stack size and the person.
As a small bag holder I actually think it benefits me more by burning 10ICP with no rewards given out than I do participating in inflation with everyone else. There is probably a bag size where this flips.
I guess it gets back to the problem is that people are already voting to take outsized rewards because of the heavy weighting to governance proposals.
It gets back to needing to reset the weight back to 1.
It also occurs to me that the need to get a boosted reward requires at least 1 proposal a day. A schedule of named neuron proposals could counteract this in the meantime and get us to a point where periodic confirmation can go into effect.
1 Like
I’ve proposed Proposal to temporarily reduce governance proposal weight to 1 which would make this proposal safer in the short term. I’ll wait to see the response to it before moving forward with this one.
The Reset proposal is live Internet Computer Network Status
I voided that one and submitted this one: Internet Computer Network Status
这是目前我看到的所有的改进提案建议中最具有可行性，对提案系统改进最小，不增加复杂度，而且实施容易成本最低，并且比较去中心化，不会增加额外的审查成本的方案，我赞成这个目前最合适的提案改进建议，希望能快速发起提案，让大家投票来实施。