Pool voting rights

[Zen-44]

With the introduction of quadratic stake rewards for mining people are incentivized to start mining on their own, and if they and their friends/family have a validated identity too, even create small family pools to cut down on resources needed to mine while maximizing income.
The old reward structure made it convenient for people to delegate to public pools. Currently, people who want to start their own friend/family pools due to security considerations (protecting large stakes from the pool owners) have to wait a period of time before being able to delegate to a different pool. As a direct result, users are pressed to remain in their old pools.

More details on this matter can be read here.

[0JustinMiles0]

Thanks Zen. I think it would be useful to have a comparison table that summarizes the changes in rights (before and after the IIP) for the different concerned parties (undelegating identities, pools, newly created pool etc.).

[Zen-44]

The voting rights ultimately remain the same. The changes allow people undelegating to immediately re-delegate to a different pool and discriminated identities to become pools themselves while still keeping voting discrimination in place.

A pool will have voting rights if at least one delegator has them, where before only identities that did not recently undelegate could become pools or take part in one.

Pool voting rights allow this restriction to be removed without losing on the discrimination side.

[Zen-44]

It's also worth noting that it also fixes the issue of newbies being allowed to delegate to an address, which allows for a micro pool attack since their micro pools would have voting rights even if their only delegators don't have them.

[midenaio]

@Zen-44 Thank you for submitting the proposal.

There is a concern that pools will be able to use the proposed mechanic to avoid mining penalties.
If they get a penalty, they could undelegate immediately and delegate to a new pool address.
Could you propose a solution to mitigate this problem?

Also the phrase is not quite correct:

Newbies are allowed to delegate to any address, and thus are able to gain voting rights during the time they should be discriminated.

Currently if a pool only consists of delegated newbies, it doesn't have a voting power, it is still discriminated.

[Zen-44]

Hey @midenaio , thanks for the feedback!
Please excuse my ignorance regarding the wrong information presented in the last form of the IIP.
This change would indeed allow a pool to bypass one penalty per epoch like it was possible before this restriction.

The first solution that comes to my mind is to use the already available data to determine if the pool to which the address was delegated has a mining penalty. Delegation would be allowed only if:

• the address stored in its "pendingUndelegation" field does not have a mining penalty (and there is no mining penalty pending to be added to the validator list for the pool address (period between the penalty being confirmed and the validator list being updated))
  OR
• if the "undelegationEpoch" is different than the current epoch.

However, in the following scenario: address A undelegates from pool X (pool X does not have a mining penalty); if pool X receives a mining penalty sometime after the undelegation (before the upcoming validation session), address A would still not be allowed to delegate.

Even if the penalty status of the pool at the time of undelegation is stored, some problems still arise since the moment an address pays off its penalty is not treated as an event (as far as I know).

I believe it is easier to implement a system of inheritance.

Solution

The solution that I see most fitting is for the undelegating address to inherit its pool's penalty seconds.
If pool X has 5000 seconds of penalty when address A undelegates, address A would also receive a penalty of 5000 seconds. This way the penalty can not be avoided by undelegating. Address A would have to pay its mining penalty before delegating to a different pool (*) or wait for a new epoch to start and for its penalty to be cleared.
I believe this design would further encourage delegating to trusted pools since you'd inherit your pool's penalty if you decide to leave it behind.
Note: the pool address would be incentivized to pay its penalty while having all identities delegated to it (not dormant/undelegated) in order to burn more coins instead of leaving them to be mined by different miners.

(*) - there is also the possibility of address A being allowed to delegate to any pool even if they have a penalty, but when the pool selects address A as a representative for block proposing/block verification, the rewards would be burnt. Please share what you think is more fitting!

With the current applyBlockOnState procedure, penalties are applied before running through the delegation switch procedure which is favorable. However, since the Undelegate Tx does not force an identity list update to occur, it is possible for an address to inherit a penalty that was issued after they undelegated, before the identity list was updated (chronological order: address undelegates - pool receives a penalty - identity list is updated). Updating the identity list when an Undelegate tx is mined would solve this issue.

Please do share feedback!

[midenaio]

Solution

The solution that I see most fitting is for the undelegating address to inherit its pool's penalty seconds. If pool X has 5000 seconds of penalty when address A undelegates, address A would also receive a penalty of 5000 seconds. This way the penalty can not be avoided by undelegating. Address A would have to pay its mining penalty before delegating to a different pool (*) or wait for a new epoch to start and for its penalty to be cleared. I believe this design would further encourage delegating to trusted pools since you'd inherit your pool's penalty if you decide to leave it behind. Note: the pool address would be incentivized to pay its penalty while having all identities delegated to it (not dormant/undelegated) in order to burn more coins instead of leaving them to be mined by different miners.

The penalties inheritance solution looks good! The requirement to pay penalties before delegation seems to be the easiest to implement. This should not be an inconvenience in most cases as large pools are rarely penalized.

[Zen-44]

@midenaio Thanks for the reply!
I have made the relevant changes to the IIP.

It is also worth noting that the way the penalty inheritance was explained still allowed for mining penalties to be bypassed by solo miners. If you are allowed to delegate to the previous pool (address stored in "pendingUndelegation" field), as a solo miner you can take advantage of this by having a pending undelegation to a pool you own, and redelegate back to it when receiving a penalty.
This scenario is on the extreme side as the one trying this would lose their voting rights and would only be able to bypass one penalty per epoch. The most recent changes contain a complete interdiction of delegation when the identity has a mining penalty.

[midenaio]

IIP-8 has been merged. Thank you @Zen-44! I think we won't need the preliminary oracle voting for IIP-8 as it only extends the protocol but does not affect the economy or security. We will include the IIP-8 changes into the upcoming hard fork update.