Repository
https://github.com/holgern/beem
New Features
- What feature(s) did you add?
To understand how my feature works I need to dive into how rewards are calculated in the steem blockchain. Whenever an account votes, the vote actually gets stored with a certain number of rshares in the database. To determine the value of a given number of rshares, you have to get both the recent_claims, the number of currently "active" rshares and the current size of the rewards pool. The formula that needs to be applied to get an estimation for the value is the following:
value = vote_rshares / recent_claims * reward_pool * sbd_price
To read up a bit more about this read the tutorial by steemit for thist
This also was how beem calculated the vote values, until I tweaked that calculation a bit. Because if were to calculate the value of a vote, which has not yet been broadcasted into the blockchain, the rshares of that vote would be missing in the recent_claims causing the upvote to seem bigger than it really is once it has been broadcasted. While the effect of this change is nearly not noticeable in the current Steem environment it has a lot of impact in an environment where one account has most of the steem power and does only vote rarely.
I made some graphs for this when I implemented this to visualize the impact:
This really shows that the higher the potential vote, the higher the impact on its value. But to be honest this graph already is in absurd levels, since 
Another graph to show the same thing: impact gets higher, the bigger the hypothetical upvote is.
To further visualize this, I will show a REPL session checking the upvote value of the 
>>> from beem.account import Account
>>> steemit = Account('steemit')
>>> steemit.get_voting_value_SBD(not_broadcasted_vote=True)
2465.814621646523
>>> steemit.get_voting_value_SBD(not_broadcasted_vote=False)
2474.4767294899793
As you can see even for the biggest account on the blockchain, the difference is only 8 dollars, so it most likely doesn't matter a lot anyways.
I got a little fun fact for ending this point: every downvote is bigger than an upvote of the exact same size. To proof this, I got a little REPL session for you again:
>>> from beem.steem import Steem
>>> stm = Steem()
>>> stm.rshares_to_sbd(1e16, not_broadcasted_vote=True)
13474.605985050803
>>> stm.rshares_to_sbd(-1e16, not_broadcasted_vote=True)
-14010.700287696967
- How did you implement it/them?
After I knew what I wanted to implement and how that will work, the implementation was rather easy. The first thing I did after looking into the beem code where the vote values get calculated was to fix a missed DRY (Don't Repeat Yourself) case, where the vests_to_sbd function was nearly the same as the rshares_to_sbd function. I changed the vests_to_sbd function to transform the vests to rshares using the built in function, and then transforming these to sbd using the rshares_to_sbd function
Then I went on to actually implement my feature. In fact all I had to do to get it working was to make this little change. In fact I only add the rshares of the vote whose value shall be calculated to the recent_claims. The rest of the changes I did were only changes to make it configurable. I chose the following defaults for the function because of the following reasons:
rshares_to_sbd
For thershares_to_sbdfunction I chose thenot_broadcasted_voteparameter to beFalseby default, since I think that normally users use that function when they e.g. stream votes from the blockchain.sp_to_sbdvests_to_sbd
For thesp_to_sbdandvests_to_sbdfunctions I choseTrueas the default parameter setting, since I believe that when people use these functions, they rarely try to get the value of an already existing vote, but rather want to know how much an upvote with that much SP / vests would hypothetically be worth.get_voting_value_SBD
For theget_voting_value_SBDfunction of the beem.account module, I also choseTrue, and I think it is pretty clear now why I chose this.