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. I also like the idea to display remaining voting strength in the UI. Otherwise I'm neutral. I don't think the system and community have had enough time to adapt to HF19 to really know what changes are needed, and I think development priority should focus on UI improvement before blockchain rules.
Thanks, perhaps you're right about timing, but I was not active for the pre-HF19 discussions so floating ideas to see what sticks. The decrease in same-user-votes power will not really affect friends, that's important too.
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?