Closed strictlymomo closed 6 years ago
yes, unfortunately the user must store a piece (the salt) of the committed data off-chain in order for the system to be secure, as transactional data on ethereum is open and readable. in our implementation of PLCRVoting, to hide the crucial input data (vote option), during a commit-vote transaction, the ui hashes (1) the user's vote option (for/against) and (2) a random number (salt) so that when it comes time to reveal-vote, the user can submit the salt to unlock their committed vote option. lemme know if that's unclear or if you think of something else!
thank you for the explanation!
are each of these JSON files valid to be resubmitted?
in the current implementation, if a user commits for a poll twice, the previous commit is no longer valid. however this is something that we'd like to change.
more details: a user can send multiple commit vote transactions; if the user has already committed for a poll, the previous commit will be overwritten. if the user sends a 'revealVote' transaction for an older commit, it will revert, as 'revealVote' requires that the input values correspond to the value of 'getCommitHash', which is the user's most recent commitVote 'secretHash'
closing this, as i believe we're on the same page now. but feel free to reopen if you have any further related questions!
Several unique JSONs were generated for a single vote, which confused me when I tried to claim a reward. I found the filenaming helpful, as I committed votes for multiple challenges: I was worried I would not upload the correct JSON for a particular reward.
What would the implications be for the vote/salt file to be abstracted away from the user: no longer a download, but some kind of hash that is requested by the client via the smart contract and instead requires a match for msg.sender to verify? All the user has to do is click "Claim Reward". Would this compromise security?
.json
.json(1)
.json(2)