You are viewing a single comment's thread from:
RE: Ideas for Future Rule Changes - Voting, Earnings, Maximum Social Benefits - a Discussion Document
I like the idea to impose a penalty for repeated votes for a single user. Not sure if it's feasible at scale or not, though.
What do you mean here? I think it would be possible to implement, but are you talking about knock on effects maybe and not just technical implementation?
Walking the voting graph every time a post pays out seems like a lot of computation. My gut feeling is that it might not scale to the sizes and speeds that they want to reach with steem. I could definitely be wrong though. I haven't thought it through carefully or read the code. It's just a guess.
Update: I guess you'd do this at voting time, not payout time, but the concern is the same. My gut feeling is that it would turn an O(1) operation into an O(n) operation. With the number of votes that are placed, that might slow things down too much.
No it would remain roughly O(1), the look up does not grow with the number of votes to place, it's constant size per user. The implementation would be like a FIFO queue of size N, @rycharde suggests N = 10.
steemd uses a local DB to cache information, as far as I have seen from very cursory glances. The real cost would be a fixed size increase to the cache per user. As we scale this could have a big impact of witness server resources and might be an argument against it. But then again this is the job of a witness and if it's a needed feature they (we I guess!) will have to step up.
Ah right, I forgot the post suggested tracking the last 10 votes. I was thinking of all votes within a time period. The problem then becomes - what if the person self-votes 100%, then places
-9-10 other votes at 1%? Maybe you only add the vote to the queue if the vote percentage is above a certain threshold?I think simply multiplying by the weight would be the most effective instead of using a threshold.
Perhaps you have an opinion @rycharde?