RE: SMT Voting Mana Deep Dive
The point about multiple accounts is an excellent one. But with multiple accounts you can't remove the first vote at all, only add to it or subtract from it with a downvote. Not exactly the same thing as changing.
Though if one can argue that the multiaccount solution is strictly better than changing, that is an argument for allowing changing, but not to the extent that it may convey further advantage or disadvantage others. Some aspects of this may be very difficult to realize in implementation.
But when it comes to the votes before such an adjustment, I don't see the conceptual difference between an event in which you change your vote significantly and an equivalent vote by another account
I believe you are talking about votes which are sequentially previous? In that case I agree, which is why I said that when your vote is last, changing it can be allowed without penalty.
But...on second thought even, that is not entirely true. Your vote might have discouraged others from following and then once you remove your vote the auction timer would be burned down. I believe the rule about allowing the last vote to change with no penalty can only strictly be applied after the penalty expires (so that mere passage of time does itself not change the state of voting).
especially in cases where one makes mistakes, which you mentioned
Another rule variant I've considered aside from being the last vote as I mentioned is to allow vote changes without penalty or with reduced penalty for some time period, say one minute, even if no longer last in the stack. Subsequent voters can consider that previous votes are not yet 'final' until the timer has expired.
You can remove the first vote at the cost of curation just like the single case, but with the proposed change, the single account will get a sort of benefit by only being charged the delta for an upward adjustment. Hmm.
Yes, but I mean distinguishing between
a) account changing vote, say reduction by X rshares
b) different account coming in and downvoting the same amount of rshares
To anyone that has voted before this event, it looks the same.
Under the "set curation weight to last vote" proposal, we could still apply an adjustment penalty on top, for example. And make it so that the curation weight cannot be larger than what it was * penalty. Something like that. Maybe that's too complicated, but probably not much more than curation is already :)
That's not a benefit relative to multiple accounts. With an original vote of A and a new vote of B, the voter is charged for A+B-A. But with two accounts, the first account would vote A and be charged for A, and the second account would vote B-A and be charged for B-A, for a total cost of again A+B-A.
I think it is because I'm coming at it from the perspective that vote changing should not be normalized. There are just too many ways in which it complicates and undermines the sequential nature of voting (where voters act with knowledge of previous votes). IMO vote changing is useful in certain exceptional cases such as mistakes or new information about the content, but mostly people just just take more care in voting without expecting to be able to change it with no or low penalty.
I do agree with not incentivizing account splitting, which calls for penalties being small or zero to the extent they can be circumvented with multiple accounts (as above).
Yeah, I think you're right in that vote changing should not be a normal occurrence. Was just thinking if there is something in between the multi account (keeps CR) and single account change situation (no CR)
And yup I am not sure what I was thinking about in the multi-account scenario above, I was wrong on that point.
Posted using Partiko Android
I agree on the first point. The advantage that multiaccounting can incrementally increase votes without penalty but single accounts can't is not ideal.