You are viewing a single comment's thread from:
RE: As a rule of thumb, the optimal voting time is before 5 minutes
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.