You are viewing a single comment's thread from:
RE: A new approach to Content Reward Allocation
This downside may be insignificant considering how many people trust the same service to collect their vote, secure their private keys
Huh? I thought the private keys are client-side.
Is the proposed user interface simple enough that most people can use it without thinking?
Without thinking? I doubt it. Upvoting something good can be done without thinking. But when I rate items on a "stars" scale (Amazon, etc.), it does require thought to decide if an appropriate rating. Also if you look at how many items often get rated, there is a concentration of 5 star and 1 star ratings. That suggests to me people don't like thinking about the fine gradations.
I don't think so in this case. Augur has client side keys but that means I have to export my account and upload it to another computer if I want to use it there. I can log into this account from any computer I've tried. Maybe I'm wrong and they've worked some magic. If so, I hope they share it with the Augur guys.
The private key IS client-side, but in this system it's derived from a combination of your password (only you know) and some other info (known by the service), aka a "brain key". You can also export the WIF to other computer, and use it directly (forget the password).
That makes it sound like the other info is only known by the service and the user the service shares it with, which isn't true. The other info is public knowledge. Which means someone who has (or guesses) your password can derive all your private keys (unless you changed them from their default after registering with Facebook or Reddit).
So to everyone reading this: you better be using a strong[1] and unique[2] password. The best approach is to use a password manager and have the password manager generate the password with 256-bits of entropy for you. Also, it is better to have a separate password for your owner key that you normally keep securely stored offline (with some redundancy is a good idea too).
[1] By strong, I don't only mean long. Steemit requires that you use at least 16 characters. But if your password is, for example, just some combination of your full name plus birth date, then it isn't strong because it can easily be brute forced by a hacker targeting you specifically who knows your identity (by following the linked Facebook account perhaps).
[2] Unique is important because if you reuse the same password you use on some other service, and that service gets hacked (and they had bad security practices so that they were holding your plain-text password in their database), then a hacker who gets that hacked information from the black market can try those passwords out on your account.
Also will there by 1/2 stars (like RottenTomatoes.com) or full stars (like IMDB.com)?
Keys are kept in browser, but you trust server to serve JavaScript.
Yes, and I misunderstood your comment about private keys. I thought you were suggesting the private key are sent to the server.
The idea of the server keeping the vote secret raises two issues:
Possibility of insider abuse of the secret information (as was alleged with daily fantasy sports and contributed to potentially almost killing a billion dollar industry). This is likely a higher burden to secure compared to static javascript code.
You can't prevent people from revealing their votes early without adding even more complexity to it, and it is often (always?) to their advantage to do so. So this incentivizes votebots that talk to a private server to share their votes and collude.
Another disadvantage: doubles the transaction rate for voting. Those are likely to be the largest share of transactions, right?
And that is the problem. The star system puts much more work on the curator for the same pay or less pay? Not cool.
People might freely attach meta data to a post though like "funny" or "insightful" and maybe give different weight to different metadata but again it seems too complicated to go to a star system.