Hi @sndbox 👋 first of all, I personally really like what you guys do, well done.
@sadkitten takes a weekly snapshot. Self votes payout is always analysed relative to SP, which gives a return on investment value for self voting, or the svROI we talk about in the explanatory post.
I know @andybets, he's very competent, and I really like his steemreports tool but because it is not open source I cannot vouch for it's accuracy. It is claimed that votes are adjusted for weight, but I do not think they are adjusted for payout relative to SP, and especially changes in SP.
@sndbox is in the top 20 self voters for this week due to high relative payout of self votes to SP. I understand that many collectives self vote to fund their activities, but this is still self voting. You can find the rationale in the above mentioned post.
EDIT: I confirmed, steemreports does not take into account dynamic SP changes over the period so it has the potential to be very wrong and misleading
I think we are actually calculating different metrics here, so comparing them doesn't really make sense.
Steemreports measures the self-votes as a percentage of all votes given, whereas if I'm not mistaken, your metric is measuring self-votes as a percentage of maximum reward pool allocation possible?
Quite right, that is my point which I hope I made well enough, that comparing them is not useful.
But no, that's not my method. The metric we use is the extrapolated self vote return on investment. This means that self vote payout is determined over a given period (in this case one week) as a percentage of their investment, which is the net / available SP, and extrapolated to a year (x52 in this case) as if they voted this way all the time, to get a kind of annual return.
The net / available SP is adjusted to changes in SP to be accurate to the time of casting the vote, which is what matters to the blockchain also, and why we do it. Both our metrics are sensitive to large changes in SP over the given sampling period.
Ok, I think I get your method now thanks. Is your code for obtaining the self-voting information open source?
This limitation has always been explained in the information popup on the chart page. Whether it actually results in inaccuracy in the case of outgoing votes is IMO subject to definitional debate.
Yes, the code is open source.
I have found this limitation to be quite severe for my own metric. I'd be interested to know what you would consider this definitional debate to be in the context of your metric. Suffice to say, the metrics are incompatible.
I think that not adapting to changes in SP generally represents users intentions better, whereas adapting would represent outcomes better.
In cases of sophisticated abuse the latter approach would probably also be preferable, but your method does nothing to deal with more sophisticated abuse either.
I can see the argument for that, though I think the distinction is not clear to users. People clearly use it to argue about outcomes, which is why we're here on this thread on @sndbox 's confusion.
In what ways do you think our method is lacking in terms of more sophisticated abuse?
I think people use it to argue/reason about both intentions and outcomes.
Your method ignores sock-puppets, and whilst this is totally understandable in that dealing with that kind of abuse is a much tougher problem, it might nevertheless have the outcome of pushing abuse under the carpet, so it's out of sight but still present. With it in the open, we get to analyse the dynamics of the situation, and perhaps learn how to improve the more fundamental aspects of the blockchain. With it pushed out of sight, the problems besetting the platform are conflated and more difficult to learn from.
Hi @personz, thanks so much for your reply and kind words :)
We really appreciate projects like this that look out for abuse within the community. Thank you for your transparency and for your response.
With respect to your last point - we would suggest creating a whitelist / blacklist that could help identify outliers or perhaps communities. This post (for example) references a film project that was funded 100% through blogging and creating content. Something we hope will become a strong explanatory resource for others. Just our 2 cents.
All the best - Sndbox Team
The project will not make use of white / blacklists. If you are a high self voter then we disagree with your voting habits, whether you are a single person or a community. For example even steemcleaners do this, and their service is vital, however I have long been an outspoken critic of that practice. @sndbox is not an outlier, your self voting is very high.
I think this is a good moment to reflect on your own practices.
Hi @personz, I appreciate the explanation and am personally in support of initiatives like this to combat abuse. As part of the @sndbox team, I make it a priority to make sure our organization is neither abusive nor misunderstood as abusive.
Over the last year, we've refined our voting methods, reward usage, and growth strategy, all of which we've been completely transparent about. This why in certain cases I would encourage others to not view self-voting as flat-out wrong. The way in which it is done, its level of transparency, and how rewards are used are all critical factors to decide whether a user or account is abusive. If involved members of Sndbox only wanted to focus on rewards, we would have taken drastically different steps. As of now, I'm confident that we've struck a good balance on voting practices that best allows us to fund projects / initiatives / campaigns all of which are designed to support the value of Steem and community impact within Steemit.
I don't really expect this response to change the trajectory of your initiative (though I second the idea of creating a whitelist) and that's completely fine, I'm happy to agree to disagree. I'm grateful that other dedicated Steemians are taking on a role that we cannot, even if that means not necessarily being in alignment at times.
Thanks for your thoughts @hansikhouse, I personally enjoy your posts a lot and have been a follower for some time.
It's not surprising that collective accounts such as @sndbox behave differently that other users. Even @sadkitten is a collective account, several users delegate their SP to have no direct return on that part of their investment, sacrificing it to improve the platform a little bit.
In the pooling of resources (not only investment but time, creativity, etc.) it's normal to pay yourself out of your collective pool. On Steem this looks like self voting, or collusive voting where a central account (maybe using a bot) votes for members. When the beneficiaries list is small this constitutes a voting ring, and where it always goes back to the main account it is a ring of size 1.
I've long thought about this practice when I looked at the numbers in a months long analysis almost a year ago. Another example was @adsactly where were one of the highest self voters by actual payout value at that time (see here for details on that analysis. We've since switched to measure self voting relatively, not on absolute value. But Adsactly are still doing this, and I recently talked to the project head on this (I think, it's hard to know who is controlling the account at any time) who also claimed context of supporting users with the proceeds of self voting, etc.
When done to high amounts, I do not think the context of a collective legitimizes the practice. This is because I support the view of Steem where voters AKA curators expend some effort to evaluate whether or not a post should be voted on. I'm fine with bots performing this effort to a degree, but not simply following, whitelisting, etc. In the long long loooong debates I had regarding self voting the point often emerged that why wouldn't you self vote, since if you spent the time to write a post you clearly think it is worth something! This point makes sense, and even more sense in a collective where your goals are at least in part about supporting the collective and it's constituent members.
However it's not the only reason and not the guiding reason, as when it's brought to it's logical conclusion why should you vote for anyone else then? You need to take more into account when making that decision, or at least you should. The "should" is important here and is underwritten by my opinion, not any blockchain code. That's why the bot exists, to express an opinion via action.
I am also happy to disagree with people here and I'm always glad when that can be done with civility (though I do not require it), so thank you. I stand by my statement: consider your practices in the context of the platform, where you want it to be and the vision you support. The means matters, as does the ends.
Thanks man!
I agree with you on white/blacklisting and your approach in general. Every action on Steemit should be taken with deliberation and an understanding of the consequences. Thanks for the explanation of your perspective, I can understand it a great deal better now.
I'm still trying to understand (from your conversation above with @andybets) whether the bot is triggered by the overall amount earned from self-votes or too high a percentage of self-votes, the latter of which we closely monitor through Steem Reports. We're very careful not to take too much of our own pie relative to the whole (we assumed ~10% would be reasonable) but to be honest, I don't think we can reduce the overall amount earned since that funding goes into real-world projects and many other expenses that sustain the program.
Anyway, really appreciate the candor and we'll put out some milk for @sadkitten as she hangs out with us for a few days.
@andybets is right to defend steemreports from my critique, it's a wonderful tool that has gone a long way to increasing understanding of the Steem blockchain, exposes statistics and even patterns in activity behaviors, and works really well, displayed nicely.
However he admitted that it is perhaps not the best tool for determining abuse, and he's pointed the various caveats and "fit for purpose" implications of the service. I'm in agreement, though I think the particular shortcoming of assuming static SP needs to be addressed. In the first version of the rebooted @sadkitten code I also had static SP but I saw it has the potential to hugely skew data.
Data is just data, and statistics just statistics. Asking a question of the data and stats is what we do every time we look at it, whether we know or not, so from a human perspective there's no such thing as "raw" data. The facts are there but our interpretation is important. Because of this I always try to make explicit, what is the question we are asking here? For you it appears to be, are we self voting too much? You have defined your own level of "too much", so a simple comparison is in order.
However if we assume static SP over time (the current SP has been the current SP forever backwards) then if there actually was a significant change in SP over that time the percentages will be off. In the case of @sndbox, @misterdelegation delegated an amount to @sndbox which increased SP by about 21% on the 27th, and you increased it further by about 68% on the 29th. This is a lot.
The steemreport graphs in the initial reply made on 1st May that @sndbox captured assumed about 59k SP, whereas before 27th April it was half that. So only votes made in the preceding 4 days would have been accurate, all before would have had a greater percentage. This means that looking back from 1st May for one week, and two weeks, the true self-voting percentage is somewhat higher. @sadkitten is aware of this and makes the necessary adjustments.
In sum, your question has not been answered correctly by steemreports, the percentage of self voting it reported to you was incorrect, and the true self voting percentage is higher. Put simply, when delegation is received by an account, steemreports will skew to lower than true self voting percentages from votes made before the delegation as the comparison is between an inflated SP and the lower possible self votes from before the delegation.