[suggestion] Instant undelegation - restoring continuity

[economicstudio]

• Current system
  • SP undelegation takes 5 days.
  • UX discontinuity: After 5 days, a sudden voting value jump occurs, which is prone to be wasted.
• Proposal
  • SP undelegation is done instantly. (This isn't a joke. This can be easily implemented without double spending of voting power. To prevent abusing of too frequent un/delegation, RC requirement can be adjusted.)
  • UX continuity: Right after undelegation, voting value stays the same and keeps recovering continuously.

Technical and Historical Background: Why 5 days?

As you know, voting power (VP) full recovery (0%->100%) takes 5 days. Undelegation removes SP from a delegatee instantly, which should be that way (e.g., easy calculation of end of contract; prevention of delegatee's misuse). However, if undelegation also gives SP back to a delegator instantly, double spending of voting power is possible, i.e., use up all VP before returning and use it again.

This was true before HF20. Technically, VP was actually managed by the variable voting_power in the code. However, after HF20, voting power is actually managed by the variable voting_manabar.current_mana (denoted by voting mana hereafter), which is much more sophisticated one. Currently, VP is just a number for backward compatibility. It's directly derived from voting mana, as explained in my previous Utopian bug-hunting post: voting_power is set to zero for users who haven't voted more than 5 days.

In contrast, voting mana is a very big number proportional to the effective SP. Basically, full voting mana is effective mvests.

 'voting_manabar': {'current_mana': '948778993772',
                    'last_update_time': 1547970732},

My current (more precisely, last updated) voting mana

Implementation Details

Currently, voting mana is already added/subtracted depending on transactions. (e.g., hf20_vote_evaluator()) Thus, changing the voting mana calculation logic isn't difficult nor burden to the system.

Specifically, in the current system, the voting mana of undelegated SP is added in full after 5 days. Instead of doing this, if the undelegated amount is added as zero mana instantly after undelegation, then the mana recovery starts continuously without the chance of double spending of voting power. See the mockups for detailed examples.

Mockups / Examples

Here are mockups of steemd.com. Suppose a user has 10,000 SP but delegated 9,000 SP.

This is the current status before undelegation. Effective SP is 1,000 and will undelegate 9,000 SP.

Current system

Now if the user undelegates 9,000 SP, in the current system, nothing will change immediately. Actually, many newbies complain about this, since they can't even notice the difference at all before/after undelegation. (especially for the undelegation from a big account). Finally, after 5 days, sudden voting power and voting value jumps occur with undelegated SP.

Nothing changes until 5 days, and right after 5 days, sudden voting power and voting value jumps occur.

In particular, the voting power tends to be wasted, i.e., soon reached 100% unless the user set the timer exactly when the undelegation is finished.

Proposed system

Every change occurs immediately after undelegation. Despite the voting power drop, the actual voting value stays the same, i.e., 8% of 10K SP = 80% of 1K SP, and then increases continuously.

In the new system, every change occurs immediately after undelegation. As you can see, a sudden voting power drop may occur (depending on the existing/returning SP ratio), but voting value is actually the same and starts increasing together with voting power.

Most UIs which show voting power also shows voting value (e.g., busy, steempeak). Thus, users will not feel uncomfortable with dropped voting power, since they can easily see the voting value is the same and keep increasing thereafter. In fact, most users understand that voting power itself is meaningless: 100% voting of 1K SP is the same as 10% voting of 10K SP. Actually, this immediate change leads them to recognize that the undelegation is actually well initiated.

Benefits

• Instant undelegation 5 day return period is too long. After HF20, it is even unnecessary. The instant and continuous undelegation process can be implemented without difficulty and burden on the system. As shown in the mockup, users can see the change immediately after the undelegation, which itself is very helpful.
• UX continuity If possible, discontinuity should be avoided, as in our previous experience: HF20 Update: Restoring Continuity. My proposal enables users to have continuous voting value after undelegation. Nobody wants to set an alarm 5 days in advance.
• No voting power waste (advance plan) Many users complain that they tend to waste voting power after 5 days of undelegation process, as explained in the mockup. Thus, some experienced users use more voting power than usual before the actual return occurs, which is cumbersome and unnatural. But in the new system, voting power waste is almost unlikely, since they can well adjust for 5 days continuously.

Note: As in the introduction, "instant" is an example. While unnecessarily too frequent un/delegation can be prevented by RC, if you're still too much worried, 1 day (or anything much shorter than 5 days) return period can be implemented similarly.

[mvandeberg]

I really like this solution. Apologies for letting it sit for so long.

The implementation is really straight forward and there are no chances for exploitation. We already allow undelegation by small amounts, which create transient database objects. This would eliminate the need for those and is a more efficient system.

There is one design decision that needs to be made regarding returning voting mana. The reason for the return period is to allow voting mana to regenerate before returning it to the owner. This is what causes the spike that you want to solve. When doing an instant undelegation, we can either attempt to take as much voting mana from the receiver as possible (resulting in a <5 day period to get back to 100%), take none of it back (effectively what currently happens), or take a proportional amount back.

Using your example above of delegating 9000 SP with each of these solutions.

Return All:

If the delegatee has any voting power, 9000 will attempt to be returned. Let's say, they have 18000 in total. If they have 9000 mana remaining, then they would end up with 0 mana and the delegator would instantly be back at 100%. If the delegatee only had 4500 mana, they would go to 0, but the delegator would only receive the 4500 mana. This is important to keep voting mana regeneration consistent and avoid exploitation.

Return None:

As the name implies, no mana is attempted to be returned. If the delegatee has 9000 mana, they will continue to have 9000 mana. If they had more than 9000, they would be capped to 9000, but the delegator would receive nothing. In this scenario the mana is "burned".

Return Proportional:

In this solution, an amount of mana proportional to the delegatees voting power is returned. If the delegatee has 18000 mana, they go down to 9000 and the delegator receives 9000. If the delegatee has 9000, they go down to 4500 and the delegator receives 4500.

This proposal is great because it leverages the natural recovery of voting mana to handle all of these corner cases.