You are viewing a single comment's thread from:
RE: As a rule of thumb, the optimal voting time is before 5 minutes
If I'm reading the code right, for author rewards, it looks like the curve is:
result = ( ( rshares + s ) * ( rshares + s ) - s * s ) / ( rshares + 4 * s );
where s is:
STEEM_CONTENT_CONSTANT_HF21 (fc::uint128_t(0,2000000000000ull))
My recollection from when I looked into this a few years ago was that rewards get zonked pretty hard until they get somewhere in the $5 range (not sure how accurate that recollection is, or if it would be the same today).
It looks like the reward curve for curation might be "convergent square root" rather than the convergent linear curve, though.
ok. I guess there are two things going on.
N2/(1 + N/5)was an example, not the formula that they implemented (don't ask me why he used an example that wouldn't be implemented).n^2 / (n + 1).Here it is before converging:
And here it is after converging:
(both with log scales on the X axis)
I'll update the original post tomorrow. Out of time for tonight.
I may look into things in more depth today and possibly do a more involved writeup on this topic, but I was poking around and found an old script that I wrote to help comprehend the convergent linear curve, it spits out what the rewards would be for various accounts if they did a 100% vote and were the only vote on a post:
I'm not going to have much time to look into it more today, but FWIW, I saw an HF21 post from Steemit yesterday where they said that they expected the inflection point for post value to be 20 STEEM.
Here's that same table with % of new vs. old added:
As percentages, I'd say minnows, orcas, and whales are generally consistent with what I saw in the spreadsheet yesterday. I'm not sure why it goes down from minnow to dolphin, though - or from Minnow to your account? I would not have expected that...
Update: Here's what the spreadsheet says the curve would look like as percentage of linear (rshares across the X axis); looks like the 100% vote for SC01 would be roughly 4.25 * 10^14, so a whale would be in the neighborhood of 2 * 10^12:
Except for the downward movement after minnows, I'd say that's consistent with your script's output.
That's right, posts that generate 20 Steem + will have an advantage over posts that generate less than 20 steem. that is, the reward will be somewhat higher for posts that generate more than 20 steem +
And stated values before payment of posts show 30-32% higher values before the payment takes place. I don't know if it matters for your math.
My guess would be rounding issues and the numbers in the table only having three decimal places.
Maybe I'll play around feeding different numbers into this tomorrow. Looks like that was written before the rule change, though, so it will need to change to your formula from above and/or to
N2/(1 + N/5).I think that's something like what I described in section 3. As I understand, the square root is based on voting order. From the link above, it used to be "square root". Not sure what the difference is between "square root" and "convergent square root", though. Maybe it just means taking the square root after applying the convergent linear algorithm?
I'm having a hard time following the code, but my current thinking is that only the author reward curve matters (to figure out the total amount of rewards to give to the post), and then it splits into author and curator rewards based on the percentage. Then I'm not seeing it do any scaling of rewards based on the order (maybe it's in there in a way I haven't seen yet). It might be worth checking a block explorer and looking at the curation rewards on a post that has paid out and see if they are just simply related to the rshares that came from each vote without any "it's better to be an earlier voter" element.
One thing that is order-related is that your share of curation rewards seem based on the delta between the curved reward before your vote vs. the curved reward after your vote, so there's probably some big bang-for-your-buck potential in being the vote that pushes the rewards on a post from the nonlinear low region to the nicer part of the curve.
Interesting. Here's the convergent_square_root function from the code:
Along with the marginal changes for that curve:
And here is the mvest / rshares ordered by time of vote from this post.
Noteworthy: the lowest mvest/rshares was the last voter: @steemcurator01 with 0.00077932..., and the highest was the 3rd voter, @curx, who voted after about 4 minutes and received 0.005784... mvests per rshare. So, the 3rd voter received 7x the reward ratio as the last voter. Voters around 5 minutes were scoring around 0.0035. Even the two voters at about 2 & 3 minutes beat the 5 minute score.
Presumably, the zeroes didn't commit enough rshares to get above the rounding threshold.
(The X axis is ordered by time of vote, but it's not properly scaled, due to the concentration of voters near the beginning of the voting period.)
So, yeah, I don't know how it happens in the code, but the order of voting definitely seems to make a difference.
Do you have an easy way to see what the actual curator payouts were for the post? I'm trying to see if my understanding of how it works maps to reality.
Not really. It took me quite some time this morning. The only way I know to do it is to get the rshares from the post, itself, using the condenser_api/get_content call, and get the curation rewards from the virtual operations in condenser_api/get_ops_in_block, then marry them up using a spread-sheet or script/program.
It's probably easier to start from the curation rewards and work backwards to the post. I did it post then curation rewards and finding the right block number with the curation rewards was a real chore.
Having trouble figuring out how to get the info I want from the standard API. But in case this is helpful for you, here's how you can get some useful info about that post from SDS:
https://sds0.steemworld.org/posts_api/getPost/remlaps/programming-diary-24-the-steem/true
I believe the "weight" parameter in the votes represents the share of curation rewards, and seems pretty close to the actual payouts (I think the differences are based on the .001 resolution). Haven't figured out why that number doesn't match what I think it ought to be yet.
I had seen that a couple years ago when @cmp2020 was building his AI voting bot, but it totally slipped my mind. Thanks! Not sure if I'll have time to look at it again before next weekend, but that does look like it might be a time saver.
OK. I made some progress but am still kind of bewildered. I now think the convergent square root curve is used (in the vote operation itself, I didn't notice at first that it picked the "curation" curve since I was so used to seeing the other curve in the rewards code). I think it sets the curation-payout-weight based on the delta between the new convergent-sqrt of rshares and the old convergent-sqrt of rshares. But my numbers aren't lining up with the actual payouts on the post. I'm wondering if maybe the data structure my script is getting for the votes isn't in order.