> 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.
Great point—Schneier’s two-party protocol is the foundation... However, it suffers from the 'Last-Actor/Last-Look' problem in a client-server environment.
In a standard 2-party commit-reveal, one party always learns the result first. (Mostly servers in current setups).
By adding a Randomness Beacon (Drand) as a third entropy source, we solve two things:
No Last-Look: Neither the player nor the server knows the outcome until a specific future timestamp (the Drand round).
Forced Resolution: Since the Drand signature is public, once that round passes, the result is 'locked' by math. The server can't hold the result hostage because anyone can pull the Drand signature and verify the result themselves.
Right. In a strict two‑party client‑server provably fair system without economic penalties or extra trust assumptions, eliminating last‑actor bias requires external future entropy (or an equivalent third uncontrollable source)
Exactly. For a web app where you can't easily "slash" a server for disappearing, you need that "uncontrollable third source" to force the game to finish.
I looked at VDFs and custom MPCs, but they felt like overkill for a dice roll. Drand is basically a "pre-computed" MPC that anyone can verify with a simple curl. It hits that pragmatic sweet spot for a trustless audit without the "math homework" for the user...
For others learning about this, the attack this project addresses is someone (maybe the web server) waits until everyone else reveals their committed bits then they alone know the outcome and if it is unfavorable they don't reveal and possibly repeat the game until they get the result they want.
Oh yes, its only one commitment per call... this is a UI handling issue, will resolve it... the backend by design only takes one commitment per player, till it is resolved/revealed... Thanks
Oh ok... so then thats definitely a bug then... actually drand issues randomness every 3 seconds... so may be multiple on the same drand round has a bug... will correct that... Thanks
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...
> 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.
Great point—Schneier’s two-party protocol is the foundation... However, it suffers from the 'Last-Actor/Last-Look' problem in a client-server environment.
In a standard 2-party commit-reveal, one party always learns the result first. (Mostly servers in current setups).
By adding a Randomness Beacon (Drand) as a third entropy source, we solve two things: No Last-Look: Neither the player nor the server knows the outcome until a specific future timestamp (the Drand round). Forced Resolution: Since the Drand signature is public, once that round passes, the result is 'locked' by math. The server can't hold the result hostage because anyone can pull the Drand signature and verify the result themselves.
Right. In a strict two‑party client‑server provably fair system without economic penalties or extra trust assumptions, eliminating last‑actor bias requires external future entropy (or an equivalent third uncontrollable source)
Exactly. For a web app where you can't easily "slash" a server for disappearing, you need that "uncontrollable third source" to force the game to finish.
I looked at VDFs and custom MPCs, but they felt like overkill for a dice roll. Drand is basically a "pre-computed" MPC that anyone can verify with a simple curl. It hits that pragmatic sweet spot for a trustless audit without the "math homework" for the user...
For others learning about this, the attack this project addresses is someone (maybe the web server) waits until everyone else reveals their committed bits then they alone know the outcome and if it is unfavorable they don't reveal and possibly repeat the game until they get the result they want.
Clicking the button sometimes displays an error:
Looking at the network tab, the POST request to the commit API returns a 409 error with the message:Oh yes, its only one commitment per call... this is a UI handling issue, will resolve it... the backend by design only takes one commitment per player, till it is resolved/revealed... Thanks
This happened on the first click opening the page, no other commit request in progress from myself, although maybe it's conflicting with other users.
Oh ok... so then thats definitely a bug then... actually drand issues randomness every 3 seconds... so may be multiple on the same drand round has a bug... will correct that... Thanks
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:
Hmm... I have not been able to replicate that... Can u screenshot it ? Thanks for trying it out : )