How did DFINITY feel about this same issue last year when the overall voting power staked was much, much lower?
As this potential was not addressed in the original proposal until after it passed, it could be considered an implementation (technical design) detail.
Has DFINITY taken any time to design or brainstorm any potential implementations to address their concerns? Or, since it was a community passed proposal did they expect the implementation and design to be fully baked/thought out and ready to go in the oven?
Also, does DFINITY expect the community to build their own solutions for community initiated and led (non-DFINITY) proposals that are passed through the NNS, or will DFINITY take on the part of implementing community led and passed proposals?
I am not sure if I understand the question correctly. Given that we had default following for all topics last (governance and non-governance) we did not have a similar issue last year. Can you please elaborate a little bit more?
Yes agreed, if we can conclude on a small enhancement which makes this work, then we could consider this as an implementation detail.
And yes, we had a few brainstorming sessions within DFINITY R&D already on how to enhance this in a simple way. So far, we collected some good ideas (some of which were also touched upon in the forum) but did not find a quick solution yet.
In terms of the way forward: As mentioned here, we are fully committed to working with the community on a holistic spam prevention and voting enhancements after the major release of the SNS and suggest doing this in a new technical working group on governance.
Hi @ysyms, we are going to establish a Governance working group, where we will also cover spam prevention (and for example discuss the proposal from @rusty.scrivens above).
I think it would be great if you could provide input/participate in this working group! Short-term, as indicated by @wpb above, re-occurence of spam will most likely trigger an increase (or several increases) in the rejection fee.
Have we considered just not allowing any stranger with 10 icp to create proposals? Maybe only named neurons should be able to make proposals. This would incentives people to become a named neuron and remove spam. We would also need a way to impeach neurons. And we need a different mechanism for people to become named neurons as they would become gate keepers to their own competition.
This doesn’t help decentralization. Maybe you have a good idea for one proposal (ICP Jesse’s electricity consumption proposal), but you don’t want to vote on every governance proposal manually. In this case you should be able to submit the proposal without having a named neuron.
Motivation for spamming proposals will quickly change from increasing revenue to urging DFINITY to implement other plan and against lowering motion proposal weights or increasing costs to take away our high revenue
Agreed I overlooked this entirely. I also made this same (embarrassing) mistake when overlooking that spam doesn’t increase inflation. So, I apologize to the community for that mistake that did mislead my vote. I like the idea of prefixing it in all caps haha Sometimes, I’ll be surfing through the forum for so long that it can be very easy to overlook things towards the end of the session lol Little things like that would def. be a good fix to THAT problem haha we can solve that at the least haha
It’s silly that the solution to spam proposals was simply to reverse the decision to grant users who actively participate in governance increased rewards. The fact is that it was an excellent way to encourage greater participation in governance and the statistics show that voting participation did increase substantially while it was active. By reversing it the only people being harmed are loyal and active users who have a long-term stake in the network.
If you want to have increased rewards (therefore encouraging more participation over time) without encouraging spam proposals all you have to do is have the system look back on the past, say, 4 proposals when weighting rewards for the day that way spammers aren’t encouraged to submit multiple spam proposals every single day to increase their rewards since they’ll get the rewards anyway even if no governance proposals were voted on during that particular day.
So if you have proposals on days 1, 3, 4, and 5, then on day 7 users will still receive weighted rewards on day 7 for voting on all of those proposals even if no proposals were submitted and voted on during day 7. And if they vote on a new proposal on day 8 then the system will reward them for the proposals on days 3, 4, 5, and 8.
Problem solved. Now there’s no need to spam multiple proposals every day when proposals from previous days still give credit toward the increased rewards. Why was this so hard to understand and implement? Why go the extreme route of reversing the rewards system entirely?