The only way to get a trust-less random value is to have it distributed and time-locked three ways, player, server and a future-entropy.
In the demo above, the moment you commit (Roll-Dice) a commit with the hash of a player secret is sent to the server and the server accepts that and sends back the hash of its secret back and the "future" drand round number at which the randomness will resolve. The future used in the demo is 10 secs
When the reveal happens (after drand's particular round) all the secrets are revealed and the random number is generated using "player-seed:server-seed:drand-signature".
All the verification is in Math, so truly trust-less, so:
1. Player-Seed should matches the player-hash committed
2. Server-Seed should matches the server-hash committed
3. Drand-Signature can is publicly not available at the time of commit and is available at the time of reveal. (Time-Locked)
4. Random number generated is deterministic after the event and unknown and unpredictably before the event.
5. No party can influence the final outcome, specially no "last-look" advantange for anyone.
I think this should be used in all games, online lottery/gambling and other systems which want to be fair by design not by trust.
Clicking the button sometimes displays an error:
Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Looking at the network tab, the POST request to the commit API returns a 409 error with the message: Commitment already pending for Round 26020619. Please wait for settlement before starting a new round.The current time (in the demo) is fixed around 10 secs, but it can be anything, minimum being 6 secs (as the fastest) Drand pulse is 3 second, and some latency buffer...
Cool stuff! I seem to have found a bug — often when I roll, I get this error and no roll happens:
Error: The string did not match the expected pattern.
> The only way to get a trust-less random value is to have it distributed and time-locked three ways, player, server and a future-entropy.
Are you sure? The protocol described in Chuck Norris book Applied Cryptography seems to work fine without a randomness beacon. Once you get the commitments from all parties they reveal the nonces and everyone verifies they match the commitments and extracts the same random bits.