Show HN: Why 'provably fair' RNGs aren't trust-less, and how to fix them

https://medium.com/@rishi_36645/why-server-seed-commitments-arent-fully-trust-less-647e13ab1c91

2 3 5 months ago

Most "provably fair" games today rely on a commit-reveal model that has a subtle flaw: the server chooses its seed hash privately. This allows for a "Seed Grinding" attack where the house pre-computes millions of outcomes and commits only to the seed that favors them.

I wrote this post to explain how to close that gap using public entropy beacons (Drand). By tying the outcome to a future Drand round that neither the player nor the server knows at the time of commitment, you get a trustless result without needing a slow blockchain.

Live Demo (Dice Roll): https://blockrand.net/live.html

The logic is simple: Hash(Player_Seed : Server_Seed : Future_Drand_Sig).

I’ve written a deep dive on why traditional commitment schemes have a "last-mover advantage" and how this triple-mix eliminates it. Would love to hear the community's thoughts on the trade-off between the 10s settlement delay and the added security.

rishi_blockrand3• 5 months ago

One thing I didn't emphasize enough in the post: the 10-second delay isn't just a technical limitation of Drand. It's actually the security feature. If the delay was 1ms, a server could still potentially 'front-run' the beacon. By forcing a 10s 'lock-in' period, we ensure the entropy is truly from the future. Is a 10s UX trade-off acceptable for high-stakes games, or is that a deal-breaker for most devs?

rishi_blockrand3• 5 months ago

Github of the JS SDK https://github.com/blockrand-api/blockrand-js

Show HN: Why 'provably fair' RNGs aren't trust-less, and how to fix them

Related Stories