ReProposal to restrict rewards qualification to a threshold - Fix advertising Spam

[amircryptola1]

Has this already been funded?

[wpb]

Of course you can handle however you want, but I think the optimal work process is to crowdfund each individual proposal as a signal of community support for the proposal. Donors should not expect a refund and proposers should not feel obligated to use the previous donation (for a proposal that passed) to fund the next proposal. This spreads the risk of rejection and offers the proposer something of value in exchange for their effort. In the case of ICDevs, it’s a donation.

[skilesare]

We are funded! I’ll try to get the proposal out tomorrow.

[skilesare]

@MillionMiles want to take a stab at translating the above proposal so I can submit it in two languages?

[MillionMiles]

Sure, I will try my best

[MillionMiles]

目标

• 减少提交垃圾邮件治理建议的动机

• 保护NNS不受审查，并保持目前提交NNS治理建议的便利性（即不增加提交NNS建议的成本或难度）。

• 保护NNS选民不受广告或负面情绪治理提案垃圾邮件的影响

注：在这篇文章中，所有提到的 "提案 "都是指所有的提案，那些可以限制为治理提案，但我认为这没有必要。

解决方案

• 更新NNS dApp，使其不显示那些至少没有达到1%（或修改后）接受票数门槛的提案，除非用户选择取消隐藏它们。

• 更新NNS罐，跳过奖励那些没有获得至少1%（或修改后）接受票数阈值的提案。

• 更新NNS罐，当提案通过1%（或修改后）的接受票数提案时，延长结束日期，以配合初始投票期。

• 没有达到接受门槛的提案仍然会将其ICP作为拒绝费烧掉。

建议解决方案的实施

注意：NNS dapp在原文创建后被重新编写，所以NNS应用行的来源很可能已经改变，但这个概念可以直接转化为新的应用。

在第6027行( ic/governance.rs at 79bbd3177f6532037eb29d62b3e52a364a8103ee · dfinity/ic · GitHub )后，添加下面相应的Rust到pseudo代码中

if( proposal.tally.yes/proposal.tally.total < MIN_NUMBER_VOTES_FOR_PROPOSAL_RATIO) {continue;}`

在第5274行(ic/governance.rs at 35acac6c1113a23e2cb92329f1431c5254567e6e - dfinity/ic - GitHub)之后，添加下面相应的Rust到pseudo代码中。

let oldYesRatio = proposal.tally.yes / proposal.tally.total;

在第5284行(ic/governance.rs at 35acac6c1113a23e2cb92329f1431c5254567e6e - dfinity/ic - GitHub)后，添加下面相应的Rust到pseudo代码中。

If (proposal.tally.yes / proposal.tally.total >= 0.3 and oldYesRatio < 0.3){proposal. deadline_timestamp_seconds = deadline_timestamp_seconds + (now() - proposal.proposal_time_stamp_seonds)。

在第158行（nns-dapp/Proposals.svelte at e9dd304d8aaa96f82e91936f23d1bf0c781ae9c5 - dfinity/nns-dapp - GitHub）之后，将第159行包入。

{if proposalInfo.tally.yes/ [propsalInfo.tally.no](http://propsalInfo.tally.no) < ($UserConfiguredMinYesThreshold | 0.3) }

Line 159

[/if}

NNS前台应用团队将需要添加一个小部件，以允许改变UserConfiguredMinYesThreshold并将首选值存储在webStorage中。

这对作为NNS选民的我有什么影响？

• 投票者没有义务对提案进行投票（也不会错过奖励），直到它达到1%的赞成票门槛。

• 一旦达到1%的赞成票门槛，投票者应投票或跟随投票者获得奖励（没有变化）。

为什么这个提案能发挥作用

• NNS参与者只对垃圾邮件提案查看和投票，因为他们被要求这样做。不投票的结果是失去了治理奖励，然后在那些对垃圾邮件提案投票的人中直接分配。引入孵化期和最低支持门槛，消除了对每一个进入 NNS 的提案进行查看和投票的要求。

• 由于NNS的投票者不再需要为无法达到门槛的提案投票，每个提案必须根据其自身的优点和价值主张达到1%的最低支持门槛，才能得到整个社区的关注。

• 这个建议不会增加提案的创建或拒绝成本，因此不会给NNS提案创建者带来更大的经济负担。

• 延长跨越1%门槛时的时间段，使审议时间保持不变。

本提案的其他好处

• 增加一个最低支持门槛，可以让治理提案在NNS上显示更长的时间，确保不太活跃的NNS选民有机会投票给他们支持的孵化提案。

• 增加一个最低支持门槛，鼓励NNS提案的创建者在提交提案之前进行宣传、接受反馈和迭代，以确保他们能够通过1%的支持门槛并在NNS上进行实时投票。

NNS应用程序用户界面的变化

• 增加一个复选框，允许高级用户取消隐藏未达到阈值的提案。

• 确保提案人创建的链接可以直接链接到投票，这样他们在宣传他们的提案时就有东西可以使用。（我想你已经可以这样做了…即互联网计算机内容验证引导，但如果你没有被授权，你就会失去你的重定向…我想这是一个简单的修复。）

反对的论点/潜在的问题

1. 这不会阻止目前的垃圾邮件者提交NNS提案。
   对(1)的反驳：看看@ysyms最近的一个垃圾邮件提案Internet Computer Network Status，

   
   我们可以看到，只有0.2%的总投票权投票接受这些NNS提案。这意味着这将永远不会被展示给大多数人，投票会失败，垃圾邮件发送者会被收取他们的10个ICP。这不会影响奖励
   请记住，即使是一些获得超过1%票数的垃圾NNS提案，其中许多票是新颖的投票，只是因为该项目是可见的。如果提案者使用一些手段争取社会支持，但他们很可能也不会达到门槛。

2. 可能会有超过1%的整体NNS投票权的人对广告垃圾提案感兴趣，以获得经济利益。
   对(2)的反驳：如果整个NNS投票权中超过1%的人支持垃圾邮件攻击，增加提案成本几乎没有任何作用。解决这个问题的办法是另一个提案，进一步提高治理提案的最低支持门槛。

3. 作为一个 NNS 提案提交者，我觉得这个最低支持门槛给我提交提案带来了额外的经济负担。
   对（3）的反驳：建议的解决方案不会改变NNS创建者的提案提交成本。事实上，在该提案上线后，我们可以将提案成本降至1个ICP。如果有人提交的提案，他们认为无法通过自愿投票获得最低支持率，那么他们应该在论坛和社交媒体（Twitter、DSCVR、Distrikt）上宣传他们的提案和时间线，以便在向NNS提交提案之前获得必要的支持。如果一个提案不能达到1%的自愿支持，那么这个提案就不可能在上线时获得多数投票权并通过。

4. 这就是把关，把那些没有民众支持或没有达到1%门槛的网络的NNS提案者拒之门外。
   对(4)的反驳：保持尽可能低的门槛是很重要的，因为它仍然能有效地防止垃圾邮件。这个建议确实增加了不上网网的提案者的风险，他们可能会在没有考虑好他们的提案的情况下失去他们的提案资金。我们认为这个风险不是不可克服的，任何有诚意的提案都应该经过社区的审核，在提交之前至少能获得最低限度的支持。简而言之，这个建议确实创造了一个低障碍，但对系统中的每个人来说，这可能是一个净收益。鉴于时间和资源不是无限的，迫使深思熟虑和最低限度的支持的建议，随着活动和兴趣增加，使好的治理成为可能。

投票接受。

• 更新NNS dApp，不显示至少没有达到1%（或修改后）接受票数门槛的提案，除非用户选择取消隐藏。
• 更新NNS罐，跳过奖励那些没有获得至少1%（或修改后）接受票数阈值的提案。
• 更新NNS罐，当提案通过1%（或修改后）的接受票数提案时，延长结束日期，以配合初始投票期。
• 没有达到接受门槛的提案仍然会将其ICP作为拒绝费烧掉。

[MillionMiles]

I don’t know whether below content should be translated, please give me your opinion, thanks

@skilesare

Continuing the discussion from Proposal to restrict rewards qualification to a threshold :

Now that we’ve handled incentivized spam, I’m re-proposing this as a quick fix for advertising spam.

I’ve adjusted the percentage down from 3% to 1%. Thanks to @Kyle_Langham 's analysis we think that 0.5% would be safe, but I haven’t gone that low…we can debate the exact number.

We can also discuss if we want the check box to default to checked to hide items that have not qualified for rewards. I think it makes it more powerful and it is hard to argue that a check mark is a huge “gate”. Anyone who wants to be a power user can be by unchecking the box.

Motion Text:

[skilesare]

I think we just need the motion text.

[skilesare]

The proposal is live! Internet Computer Network Status

[rusty.scrivens]

I’ve been thinking about this and I think I see a slight problem, until 38985 - Proposal to Enable Manual Voting Throughout the Entire Voting Period of Governance Proposals gets implemented, it’s possible that a named neuron will vote on a “hidden” proposal before its followers see it and can vote independently. And once it does make it past the threshold filter it will already be voted on with no way to override that vote.

[skilesare]

That is a great point. Perhaps we can get Dfinity to comment on how close we are to that implementation.

@bjoernek ?

[ysyms]

I maybe vote no on this proposal

1. It has the practical effect of giving the review of the proposal to the admins of the dfinity forum ，NNS shouldn’t hand over such an important component to a centralized forum, even if it belongs to dfinity
2. It will privilege a small group of people
3. it will lead to active neurons help relatively inactive neurons to review proposals for meeting a minimum threshold

[skilesare]

I’d agree that there is a danger here, but the hurdle to self elect as someone who votes before the threshold is very low.

1. Uncheck a box

Or

2. Subscribe to a feed that doesn’t filter.

No one has to use the forum(although I think it is a ‘best practice’ at the moment. That will evolve as the NNS tent grows.)

If the threshold were higher there would be a bigger risk, but 1% is 1/20th of what is being voted right now and I don’t think that is very high.

I’m almost every democracy there is some threshold to get stuff on the ballot otherwise you never finish voting(Here in texas you have to get 1,000 signature or something like that).

Point three is your strongest as it certainly would advantage anyone who accumulates >1%, but isn’t that the whole point of the NNS? If you can accumulate voters you get stuff passed. The greater your accumulated stake, the greater influence. I don’t know if you can combat that given the underlying mechanism. Open to ideas.

[bjoernek]

@skilesare

That is a great point. Perhaps we can get Dfinity to comment on how close we are to that implementation.

On this proposal we require further discussion on the design. For example how should the manual voting interact with wait-for-quiet. It would be great to pick this up as a topic in the newly created governance working group.

[wpb]

The original Manual Voting proposal 38985 defined Current Vote Result and Projected Vote Result. Current Vote Result would be any votes cast manually throughout the voting period. Projected Vote Result would be the total voting power cast through the Followee system of liquid democracy. All neuron owners that want to change their vote after a Followee has already voted for them can do so by voting manually, but it will only change their own vote, not any follower vote. The Wait For Quiet would be implemented based on the Projected Vote Result. Absolute Majority and Simple Majority should be implemented based on Current Vote Result. At the end of the voting period, the Projected Vote Result automatically becomes the Current Vote Result.

This is a one time vote change for neuron owners who don’t agree with how their Followee votes. Once the vote is cast manually, it can’t be changed.

This proposal was important because it gives everyone an opportunity to vote manually while still maximizing the benefit of the Followee system AND because it enables public known neurons to vote any time during the voting period without having to wait if they want to give their followers time to vote manually (this was important at the time of the proposal to all the earliest public neurons…Synapse (ICPMN), ICDevs, and Arthur (cycledao)).

[bjoernek]

Hi all,
after syndication within DFINITY, we have the following feedback

What we like about the proposal

• Addresses a relevant topic, namely how to prevent the misuse of the NNS for placing messages/inappropriate content.
• Limits the visibility of potential spam for users in the dapp.
• It is a concrete & tangible suggestion.

Where we currently have concerns

• The issue currently does not seem to be urgent as we had very few spam proposals not related to financial incentives. We feel that the topic would benefit from further discussion & evaluation, compared to other alternatives (see next point). Potentially the governance working group could be a good venue for that.
• This proposal is one form of voting in stages. There are other designs in the same category, which in our opinion should be considered. For example one could consider a set-up in which
  • the first phase focuses on whether a topic/proposal is worth a broader discussion
  • the second phase whether one is in favor or against.

As a consequence, DFINITY opted to vote no on the current proposal. However, we would like to highlight that we believe that the proposal contains many good elements which could be leveraged for a refined solution.

[MillionMiles]

Base on the result of council votes: 2 YES/6 NO, We oppose proposal 83447, we think currently it’s too early to implementing threshold restriction for IC, this would suppress the motivation for community proposals.

8yeargangDAO