[condenser_api] voting_power is set to zero for users who haven't voted more than 5 days but has changed effective vesting shares

[economicstudio]

Project Information

• Repository: https://github.com/steemit/steem
• Project Name: Steem

Expected behavior

voting_power should show the voting power at last_vote_time.

Actual behavior

voting_power is set to 0 for users who haven't voted more than 5 days but had some transactions that affected effective vesting shares (e.g., claim reward, power up, delegations).

Even though the current voting power can be calculated from voting_manabar, the main reason why voting_power is provided is for legacy code. Since most apps use voting_power with last_vote_time to calculate current voting power.

Because of this, most developers believe that voting_power is the voting power at last_vote_time and it actually was before HF20. This reset is only for users who haven't voted more than 5 days, so despite the reset, current voting power can be correctly calculated as 100% since it's saturated at 100% anyway.

However, this inconsistency (without any documentation) can create a lot of confusion. For instance, Busy has such a problem: https://busy.org/@steemit shows the vote value of @steemit is $0.00 due to this (I already fixed this and submitted PR: https://github.com/busyorg/busy/pull/2143)

In any case, inconsistent behavior should be avoided. (another good example of inconsistency is #3184) This can be fixed by my PR: #3218

How to reproduce

• Steem version: 0.20.4-8 (current) (introduced at v0.20.4 https://github.com/steemit/steem/commit/8decb360ca4e353e175231054cc76662e52a8d17#diff-f57e2d2b973d056e18ca93986e5ed3f5)
• Browser/App version: Any
• Operating system: Any

- Pick any user who hasn't voted more than five days but has had some transactions that changed effective vesting shares, e.g., @steemit - (technical) Get the raw account information by `condenser_api.get_accounts` e.g., `curl -s --data '{"jsonrpc":"2.0", "method":"condenser_api.get_accounts", "params":[["steemit"]], "id":1}' https://api.steemit.com` or use any library that can help doing this. ``` "last_vote_time" : "2016-12-04T23:10:57", "voting_power" : 0, "voting_manabar" : { "current_mana" : "69835912701503862", "last_update_time" : 1538171805 }, ``` > excerpt of example output for @steemit

If you wanna sudden drop to zero, you need have an account that hasn't voted nor any transactions that affect effective vesting shares. Fortunately I had one, and that is included in the Recording Of The Bug section.

Reason Of The Bug

This voting_power reset is mainly due to the introduction of voting_manabar at HF20. Even though the correct current (not last) voting power can be calculated from voting_manabar.current_mana with voting_manabar.last_update_time, Steem still provides voting_power at last_vote_time for legacy code (most apps still use the voting power).

Here is the condenser_api that computes voting_power

https://github.com/steemit/steem/blob/69c94e4f570fa3d0b14c83d8dec4626d3455f8b8/libraries/plugins/apis/condenser_api/condenser_api.cpp#L2090

But L2090 always set voting_power to zero when vp_dt > vp_t2u

By vp_dt = STEEM_100_PERCENT * dt / STEEM_VOTING_MANA_REGENERATION_SECONDS, vp_dt > STEEM_100_PERCENT is equivalent to dt > STEEM_VOTING_MANA_REGENERATION_SECONDS (5 days).

But dt is difference between voting_manabar.last_update_time and a.last_vote_time and therefore voting_power is set to 0 for users who haven't voted more than 5 days but has some transactions that affect effective vesting shares (e.g., claim reward, power up, delegations), which updatesvoting_manabar.

Fix

This fix returns the previous a.voting power when this reset happens (unless current_mana is 0, case 2 below).

This fix is safe cause vp_t1 = 0 can occur only in the following two cases:

1. 5 days passed current voting power (calculated from a.voting_power and a.last_vote_time) will be 100% either way. But this fix is more informative, since it returns the last voting power.

2. vp_t2u = 0 L2085 return 0 (same as before)

Recording Of The Bug

Let me explain this with my subaccount @economicstudio (same name with my github account :).

@economicstudio's last vote time is 'last_vote_time': '2018-10-26T16:04:06', much more than 5 days ago. But it also hasn't done any transactions that affect effective vesting shares.

before powerup: last voting_power 96.94% is correctly shown

after powerup 0.001 SP: last voting_power is reset to zero!

Only the voting_manabar is actually used to calculate the vote value on the blockchain, so voting_power is purely for convenience and backward compatibility. Then why not providing more meaningful and consistent information?

GitHub Account

https://github.com/economicstudio