Show HN: Why 'provably fair' RNGs aren't trust-less, and how to fix them(medium.com)
medium.com
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
3 comments
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?
Github of the JS SDK https://github.com/blockrand-api/blockrand-js
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.