Idea for random number generation

[jameswestman]

Just a thought I had about distributed random number generation. If I understand the game rules correctly, the only time you need randomness is at the beginning of each round, correct? If not, this will be a little trickier, but the concept should still be usable. Here's the basic setup:

• At the beginning of each game, each player generates a large, random number and keeps it secret. They repeatedly hash it: SEQ(n) = SHA256(SEQ(n - 1)). They post SEQ(1000) to the room.
• When a player has received all other players' SEQ(1000), they post their SEQ(999). This is "turn 0".
• When everyone has done that, the game can begin. The initial seed is the XOR of everyone's SEQ(999).
• With each turn, you must post SEQ(998 - turn_number), and it is XOR'd with the current seed to get the new seed.
• When a random number is needed, it is generated from the current seed.

The idea is, by posting SEQ(1000) at the beginning of the game, you prove that your RNG sequence is set in stone and you can't change it later. But, because hashes are irreversible, nobody can predict the next number in anyone else's sequence--only verify it once it's been revealed.

Advantages:

• Impossible to cheat without getting caught (if I didn't overlook anything)
• Does not require everyone to be active in the room for the whole game, only at the beginning and on their own turns

Disadvantages:

• Requires each player to keep their own secret, which might be difficult in a distributed widget? I'm not sure.
• Does not work in scenarios where players may choose to draw a card, because they could "peek" at that card before deciding whether to draw it
• It's kind of complicated

[toger5]

This is really interesting and reminds me of where I was heading with secrets in general.
The idea was, that each player is doing things (like drawing a secret card) based on some secret seed but still beeing able to prove at the end of the game that the player was not cheating.
For that proove the hash of the seed is shared in the beginnning of the game. The other player can than check if all the cards the player has drawn and the hash fit to whatever the other player claims to have used as the seed.

For random numbers in particular i think the easiest still would be to use the origin_server_ts as the seed.
It has all the same advantages but is super simple to implement if the widget api would allow to reliably query it.

storing a secret in a shared context is a little bit complicated. You cannot just store it in the widget state (that is ont secret).
But it also cannot be stored in the widget. Another room could be created. An encrypted room for each player where they store their persistent secret data. I dont know if there is some acocunt data the widget has write acces too and that is not available to the public.