Add player-specific salt

[norswap]

Currently, we pick a random number (which is based on blockhash of the previous block) and use that to draw cards. The problem is that the opponent can see this random number too, and thus predict drawed cards.

To avoid this, we need to let each player pick a random salt in advance and commit to it on-chain by posting its hash. Henceforth, the randomness used to pick their card is a combination of the blockhash (which they can't predict) and the salt (which the opponent can't see). The zk circuits take the salt as private input and the salt hash a public input, verifying that the two match, and deriving randomness by combining the salt with the public randomness.

[Boffee]

Can you generate the salt by having players sign some unique deterministic game state (e.g. gameId + turn #)? Wouldn't need to commit anything in this case.

[norswap]

You could, but I think verifying ECDSA signatures is expensive.

Yup, see here: 45s proving time on a AWS large, and I think that's using the C++ implem, not the MUCH slower WASM implem we're using for client-side proving. Mayber other proving schemes do better? (Noir will have a builtin for it.)

Using another signature scheme (are there zk-friendly signature schemes? good question) would require committing to a public key, so it doesn't help.

[Boffee]

Oh I was thinking create a unique signature for each draw and just use ecrecover to verify in solidity instead of in the proof.

[norswap]

Ah interesting! That wouldn't be ideal because then the opponent could know the random numbers we use to draw from our deck, which isn't initially shuffled.

Also, we do need the (secret) salt to fudge the commitments to the hand & deck (previously merkle roots, soon to be flat hashes).

[Boffee]

Oh ya, you're right, the signature should be revealed when the card is played instead of drawn so that the random number is kept hidden.

[norswap]

Fixed by #58, #60, #61