[condenser_api][0.20.4-8] voting_power is set to zero for users who haven't voted more than 5 days

in #utopian-io5 years ago (edited)

Project Information

I've opened the issue and also submitted PR.

Issue: https://github.com/steemit/steem/issues/3217
PR: https://github.com/steemit/steem/pull/3218 (merged)

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 (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 https://github.com/steemit/steem/issues/3184) This can be fixed by my PR: https://github.com/steemit/steem/pull/3218

How to reproduce

  • Pick any user who hasn't voted more than five days but has some transactions that has 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

Sort:  

Hi @blockchainstudio, thanks for this contribution. It adds significant value to the open source project in question.

I love that you explained in detail how the bug came about. Since the introduction of voting_manabar at HF20, there have been numerous bug reports concerning the vote power.

It is particularly strange that in this case - the voting_power is set to 0 for users who haven't voted more than 5 days but had some transactions that affected effective vesting share.

I see that your pull request was recently merged to the master branch. The measures you took to fixing the error are also laid out for easy reference. Great job, this post meets the criteria for a staff pick and has been staff picked :)

NB:
Can you edit and move the device and software details (browser version, device os, app version) to the bottom of the post? Also, the
submission title in future contributions should be in the format ([Product Name] [Product Version] – Succinct description of the bug). Thanks again for the contribution :)

We look forward to your future reports.

Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.

To view those questions and the relevant answers related to your post, click here.


Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.
[[utopian-moderator]](https://join.utopian.

Hi @fego, thank you for your review and comment. I've changed that way. Thanks!

Thank you for your review, @fego! Keep up the good work!

짱짱맨 호출에 응답하여 보팅하였습니다.

Summary in Korean: 제법 테크니컬한 부분이라 모르셔도 아무 지장없고 손해보시는 분도 없으실 겁니다. 얼마전 네드가 깜짝 보팅하기전까지 네드 보팅가치가 busy에서는 $0.00으로 보이던 것과 관계있는 것인데 이게 본질적으로는 busy의 문제도 있지만 Steem자체의 문제이기도 해서 리포트 하고 수정까지 했습니다. 보팅봇등을 위해 프로그래밍 해보신 분은 아시겠지만 voting_power가 last_vote_time 즉 마지막에 보팅했을대의 보팅파워값인데 이것이 5일동안 보팅을 안했지만 유효스파에 영향을 줄수있는 직접적인 트랜잭션(보상 클레임, 파워업, 임대, 파워다운 등)이 일어나면 이 보팅 파워가 0이 되어버립니다. 물론 5일이 이미 지난거라 현재 보팅파워 계산하면 무조건 100%가 이렇든 저렇든 나오기에 사실상 영향이 busy처럼 이걸 계산에 아예 안넣은 경우 아니면 문제가 없긴합니다. 하지만 voting_power라는 값이 경우에 따라 다른 값을 나타낼 수 있는 이런 inconsistency는 항상 다른 문제를 일으키기 마련이고 고쳐야한다고 생각해서 고쳤습니다. 실제 왜 0이 될까 궁금증을 못참고 들여다 봤네요ㅎㅎ 그리고 기어이 고쳤는데 안고쳐도 쓰는 사람이 잘 알아서 쓰면 상관이 없긴해서 merge해줄지는 모르겠네요. 되면 스팀 블록체인 코어에 제 코드 올라가는 거라 되면 좋겠습니다^^

Hi @blockchainstudio!

Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your post is eligible for our upvote, thanks to our collaboration with @utopian-io!
Feel free to join our @steem-ua Discord server

Hey, @blockchainstudio!

Thanks for contributing on Utopian.
Congratulations! Your contribution was Staff Picked to receive a maximum vote for the bug-hunting category on Utopian for being of significant value to the project and the open source community.

We’re already looking forward to your next contribution!

Get higher incentives and support Utopian.io!
Simply set @utopian.pay as a 5% (or higher) payout beneficiary on your contribution post (via SteemPlus or Steeditor).

Want to chat? Join us on Discord https://discord.gg/h52nFrV.

Vote for Utopian Witness!

Coin Marketplace

STEEM 0.39
TRX 0.12
JST 0.040
BTC 70118.22
ETH 3546.28
USDT 1.00
SBD 4.89