Voting discrimination

[Zen-44]

Currently, pool identities can undelegate from a pool (if they did not delegate during the same epoch) and instantly receive their voting powers back. This means that large pools can incline the voting outcome of an oracle voting or even a hard fork voting.

An example of this happening was the last hard fork, on 17th November, when the voting number was stagnating right below the threshold for the hard fork to be activated. Two pools with a significant number of delegators performed an operation where a significant number of identities undelegated, turned on mining (voted on the hard fork), and after the hard fork was activated they redelegated to their pools.
Reference blocks where some of the related transactions were confirmed:
3636579,3636615,3636660 and 3636661 (undelegation); 3636606,3636653,3636654,3636706 (mining status turned on); 3636769 (hard fork activation); 3636871,3636872 and 3636873 (redelegation)

This was a happy example where the voting was only inclined by a small amount and was done so the upcoming validation at that time would have the bug fixed and people would receive their rewards correctly. But with the same mechanics, a potentially larger pool could do exactly the same thing in the future at a larger scale in order to manipulate the outcome of governance votes or simple oracle votings. This also has a negative effect on oracle locks, because a large pool could change the outcome of an oracle voting and make the funds locked in oracle locks go to a different address than intended. Currently, pools with a large number of delegators that did not delegate during the same epoch have the same voting power as everyone else in the network since they can just undelegate and cast their votes.

Having voting powers removed completely from delegated identities even if they remove themselves from pools would incentivize killing your identity and starting a new one to regain your voting powers.
What I propose is having identities discriminated against after they undelegate from a pool for at least one month (or 2 epochs if those represent more) in order to prevent vote manipulation of forks and oracles. Do you consider this is enough time? Or too much of a timeout? What other solutions do you consider?

[Zen-44]

Current version of the IIP: https://github.com/ZenMaster420/idena-docs/blob/main/docs/iip/iip-3.md [removed - PR merged]

[Zen-44]

teajunction on discord proposed having newly validated identities discriminated as well to remove the possibility of farms re-inviting their identities (using their own invites) to take part in a voting.

Discord conversation for reference: https://discord.com/channels/634481767352369162/941971918704218152/942538019532046367

[Zen-44]

IIP updated to address the raised problem.

[midenaio]

@ZenMaster420 thanks for the proposal. There is some feedback on that.

1. To avoid complexity the discrimination period should be aligned to epochs (not months). Thus, the discrimination of undelegated identities ends with the beginning of a new epoch. Now the epoch is 21 days. It’s 28 days for the network 16.2k+.
   The possible duration of the discrimination period can be 2 full epochs and plus a part of the epoch in which the undelegation occurred.

2. Discriminated identities of large pools may try to attack the blockchain consensus after a fork is activated. Assume that discriminated identities vote against the fork by running the old node version that does not support the upcoming fork. Since the votes of discriminated identities are not counted during the fork voting, the fork will be successfully activated. However after the fork is activated, block mining may get stuck because discriminated identities are still running their outdated nodes.

   There are changes required for the block consensus mechanics:

• Discrimination should affect the blockchain consensus mechanics where mining nodes vote on the proposed blocks. The votes of discriminated identities that were included in the block committee should not be counted. This will ensure that mining of the blocks will be successfully continued after the fork is activated even if discriminated identities voted against the fork.
• Discriminated identities will be rewarded for the mining as regular identity.
• Discriminated identities’ votes for blocks will be used only to identify their online mining status.
• Discriminated identities can propose blocks and get paid for that as regular identity

3. Let’s specify ‘newly validated identities’ as ‘Identities with Newbie status. Normally you can get verified after 3 validations: Candidate->Newbie->Newbie->Verified. It means that votes of newly validated identities are to be discriminated across 2 full epochs.

4. Newbies should not be able to vote in critical Oracle votes (e.g. fact certifications or making decisions)

5. A pool owner can try to attack votes by creating lots of micro-pools with 1 identity each. To prevent it, an undelegated identity should not be able to delegate to a new pool address during the discrimination period. However, the discriminated identity can delegate back to the previous pool address.

6. Pool owner should not be able to terminate undelegated identity during the discrimination period.

[midenaio]

Great job, thanks a lot and congrats on the first IIP!

[Zen-44]

Thanks for merging my proposal! I am curious what is the next step, will an oracle voting take place? If so, how will it be funded?

[Zen-44]

+1 @midenaio

[midenaio]

@ZenMaster420 I do not think we need an oracle voting for this proposal because it affects the protocol security. We'll implement these changes in the upcoming hardforks.

[Zen-44]

Alright, good to hear! 😃