How to Modify Steem Curation Such that Voting is Blind
Here I propose a method to make curation voting blind to voters, which will reduce swarm voting (voting where later voters blindly follow early voters) and may also reduce the incentive to vote with a bot.
Bot voting is a potential problem for curation
Recently, it has been observed that a number of users have been using bots to automatically up-vote Steem authors who have a good track record of contribution. Steem developer Dan Larimer (@dan, @dantheman) conducted an experiment requesting users to not up-vote his post describing the experiment. The results revealed that many users up-voted the post, most of these likely were bots that did not evaluate the post beyond determining the author. Voters have a strong incentive to use bots because the Steem reward system weights early votes much more than those that come later.
Bot voting is a curation problem because it removes any incentive for curators to review submissions. Once a bot has voted on behalf of a user, the user has little reason to visit the post and override the bot's decision.
Curation is a Schelling game
Curation voting can be considered a Schelling game where voters try to identify the post's Schelling point, which is the vote most likely to be cast by future voters. Essentially, each voter must decide from available information whether later voters will vote for the post. This information has three primary sources. The first is the subjective quality of the post content. If curation were a perfect game, post content would be the only source of information. If the post content is subjectively good, then the Schelling point is the up-vote. The second source is the body of decisions revealed by curators who have previously voted on the post in question. This source of information leads to swarm voting because the obvious Schelling point is the consensus of previous voters. The third source is the author's track record, where the Schelling point is an up-vote if the track record is positive. This latter source of information leads to bot voting, which will establish a Schelling point that then leads to swarm voting.
A blind voting scheme requires limited cryptography
All sources of information not directly pertaining to the subjective quality of a post cannot be fully eliminated, although this information may be reduced. One way to do this is to use a blind voting scheme, where a voter does not know the votes of other curators. A blind voting scheme may be accomplished using a system with very little cryptographic overhead. The system I describe is inspired by Vitalik Buterin's proposed system for a price feed.
The essence of this blind voting system is to have voting rounds wherein voters commit votes without initially revealing them. After each round is over, the voters reveal their commitments as a requirement to earn rewards.
Commitment C would be:
C = Hash(V + R + Hash(R + W) + K)
Here, V is the vote, encoded as 1 for an up-vote and 0 as a down-vote, R is a 256 bit random number, W is the voting weight, and K is the voter's public key. The term Hash(R + W)
prevents the voter from changing votes by simply changing W, as would be possible with a commitment of the form C = Hash(V + R + W + K)
. The large size (256 bit) of random number R prevents other voters from trivially decoding the vote by brute force.
At the end of each voting round, voters must reveal V, R, and W. The reveal step requires no effort from the voter because this step can easily be automated by the voter's client software.
Reputation can attenuate voting power
If this system were coupled with a reputation score that attenuated voting power based on vesting, voters could compete for reputation. The mechanism would be one wherein curators that vote with the consensus take reputation from those who vote against consensus. Additionally, Sybil attack would be prevented in the same way it is currently, where voting power is weighted by vests. Inconsistent or incomplete (not revealed) votes would not be counted and would carry a penalty of approximately the same magnitude as minority voters.
A blind voting system can reduce bot and swarm voting
This system would reduce bot voting because it would give time for curators to review material before being pressured to vote--in contrast to the current system where milliseconds matter. Additionally, later voters would not be able to freeload one the work of early voters because the results of the work would not be visible. Each round of voting could be scored independently, without taking into account earlier rounds, reducing (but not eliminating) the influence of earlier rounds on the Schelling points of later rounds.
Not bad.
The biggest barrier, from a user experience point of view, is the fact that users cannot simply vote and close their client for days and expect it all to work. One way around this is if the user trusts steemit.com to neither "front-run" them by using the information in the reveal to their advantage nor hurt them by refusing to broadcast, they can optionally send the signed reveal transaction (with sufficient expiration time far enough into the future) to steemit.com servers at the time of voting so that Steemit can then submit it to the blockchain at the appropriate time. The user choosing this path (which would not be mandatory) could even send the reveal transaction themselves (whether Steemit does or not) if they happen to be online at the right time, thus making Steemit act more as a backup plan.
Also, your commitment scheme seems on one hand unnecessarily complicated, and on the other hand not resistant to abuse enough. I would just use:
where
U
is the account name of the voter, andW
is the voting weight (from -100% to 100%). TheU
is needed to prevent other users from simply copying the commitment of other big players they want to vote in a similar way to. The signed commitment transaction would of course be constructed to associate this commitment by the known voter to the particular post that it is voting for. The signed reveal transaction would be constructed to be associated with the commitment transaction.I'm not so sure penalizing people for a contrarian vote is a good idea though. I agree there should be some penalty (not exactly sure of what) for not finishing the reveal process correctly. But I don't think someone simply voting against the trend should be penalized any more than the cost to their voting power to vote in the first place. So I am very hesitant on a reputation system where it can be taken away by the other curators for not voting with the crowd. The benefit to voting with consensus would be higher payout in curation rewards. The closer you are aligned with the consensus value, the higher your weight for the curation payout fraction (still weighted by your SP of course). So the only cost of a contrarian vote other than using some voting power would be opportunity cost, which is already the case today.
The advantage of hidden votes is that during a round, there is no trend established against which a voter would be contrarian.
Voters need to be known so vote can be tied to bandwidth limits and voting power. The public nature of the vote is useful so that not every one has to vote. People don't keep their client open.
Good ideas, but there are human factors that are incompatible. There is a solution.
The protocol doesn't hide voters, it hides their votes.
The only downside is that a client needs to be open to reveal votes. This doesn't have to be a continuous process. Mature votes could be revealed when a user logs in.
Make it sense using something like that?
Wouldn't work, since you can interact with the blockchain using the cli_wallet.
Then how do people tell if my content is posted by me? If I post under officialbeyondbitcoin...and 3 other people do the same before me...people are highly unlikely to vote mine up.
In this scheme, author of the content would always be known a priori, and voters at the end of each round would be known a posteriori.
Ahh I see.
Actually the voters would be known a priori as well. It's just that the way they vote would be blinded until the reveal stage of a round. Short of redesigning the system and using fancier cryptography (e.g. RingCT) to constantly mix "bandwidth coins" (for lack of a better name), the submitter of any transaction (including the vote commitment transaction) must be publicly associated to an account on the blockchain.
But this doesn't solve the auto-voting based on the author, which is I think the bigger problem here.
Is that really a problem? Why wouldn't a user want to maximize rewards based on the current schema? Everyone else knows the rules and are allowed to use whatever is at their disposal to 'play the game.'
For the record, I only think an autovote bot is only good until the 4th of July. After that, a sophisticated suggestion algorithm will be better.
So in other words? A post should be anonymous, and after a period of time, should reveal the name?
Nothing is anonymous. The votes for a particular voting round are not revealed until after each round.
Are votes on the blockchain?
Yes, the commitment is stored in the block chain as a hash, equal to 32 bytes total. The vote is then revealed later, requiring the weight and vote, maybe 2-4 bytes, plus the random number 20-32 bytes depending on what a suitable level of security is.
crap.. downvoted with no reason :/
You can change your vote in the CLI now. I think you can change it on steemit.com too, but I'm not sure.
What if bot's are voting only author's... independently of accumulated votes? How will you prevent this?
If a bot knows whats good or bad, maybe it should be rewarded ... in other words, lets reward people for the human factor somehow
Very nice !
I was wondering what happens if a bot voted and what's being done about it. Thank you on writing about this situation that's been circulating in steemit
I think this is an interesting development. I don't have a problem with the way it's done now, though I see your point about people upvoting a post just so they can be first in case the post gets popular. How would this affect your use of your own voting bot?