kangarang / tcr-ui

A client-side shell to interact with token-curated registries
MIT License
68 stars 28 forks source link

Too much salt! #99

Closed strictlymomo closed 6 years ago

strictlymomo commented 6 years ago

screen shot 2018-05-31 at 9 46 00 pm

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

{"voteOption":"0","numTokens":"100000","commitEnd":"05/31/18__21:28:23","revealEnd":"05/31/18__21:38:23","listingID":" Gibraltar Sunset 7th October 2011","salt":"345892961127008710424429545420554227334127191112985361130594539114","pollID":"9","secretHash":"0xeba2d521dc8a0c6acc76f82750532c653bf6c734f2c61c7055a43fc7e4d21f1d","account":"0x2dabb24e53b5d14980cb9df20d05bcfd3a9f4b0f"}

.json(1)

{"voteOption":"0","numTokens":"100000","commitEnd":"05/31/18__21:28:23","revealEnd":"05/31/18__21:38:23","listingID":" Gibraltar Sunset 7th October 2011","salt":"341208019377122157734438512321125355920957496442549332077489832333","pollID":"9","secretHash":"0x53cb8b02df5ec76474eb2da7bdef8b31e1c43b0cf5e36cc7c29c497e0383a2f5","account":"0x2dabb24e53b5d14980cb9df20d05bcfd3a9f4b0f"}

.json(2)

{"voteOption":"0","numTokens":"33333","commitEnd":"05/31/18__21:28:23","revealEnd":"05/31/18__21:38:23","listingID":" Gibraltar Sunset 7th October 2011","salt":"332560236240340155412094222311158620140612723165947421012512710610","pollID":"9","secretHash":"0xa3c4c3f2ce46180bc62681a5d9e08113faa7927f513e1d91cb67c26abf44e2af","account":"0x2dabb24e53b5d14980cb9df20d05bcfd3a9f4b0f"}
kangarang commented 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!

strictlymomo commented 6 years ago

thank you for the explanation!

are each of these JSON files valid to be resubmitted?

kangarang commented 6 years ago

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'

kangarang commented 6 years ago

closing this, as i believe we're on the same page now. but feel free to reopen if you have any further related questions!