[Xorlof]

Those not interested in the techie stuff Lyrgard and I have been discussing, skip the spoiler. Really. It's something we could do via PM, but doing it in public lets others point out anything we've missed.

Spoiler Alert!

Lyrgard--In my defense, that page didn't exist when I last searched for such things 2 years ago. I did do some more searching last night and quickly discovered that what we've been discussing is called "bit commitment" protocols in cryptography. Searches for THAT include lots of algorithms, including what I came up with for method 3.

Your criticism of my method #2 is spot-on. It would be best used where network latency is an issue, such as more real time games. However, I just thought of a way to reduce the latency of method #1 down to basically the same as method #2:

1) Each peer commits to (for example) 128-bits at the start of the game by sending the hash of it.
2) When dice need to be rolled, all peers reveal their 128-bits. In the same packet, commit to a new set of 128 bits to be used whenever the next dice roll is needed. Check that the revealed bits match what was committed to in step 1 or a previous round of step 2, XOR them together, and use the output 128 bits to determine the dice rolls needed (e.g., 1d20, or 6d6).
3) If any peer ever drops and loses the previous values that it committed to, it reconnects and commits to a new 128-bits. If the drop occurred after any other peers had already revealed their 128-bits (i.e., in the middle of a dice roll), all peers re-commit, and then re-reveal. (And flag the dropped peer as doing something suspicious).

Additional safety could be added by making the committed bits able to be calculated in a non-parallelizable way that requires quite a bit of time (e.g., hours). The no committed bits would ever *have* to be lost. I haven't thought through how to do this. It seems feasible, but is probably more interesting as a brain exercise than a necessary feature.