You are viewing a single comment's thread from:
RE: As a rule of thumb, the optimal voting time is before 5 minutes
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).
It looks like the reward curve for curation might be "convergent square root"
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.