Everyone talks about “provably fair” games, raffles, and loot boxes — but in practice, most implementations still require players to trust the server.
Think about it: the server commits a seed, the player sees a hash, and after the game, the result is revealed. Technically, the house could precompute outcomes and cherry-pick them — even if it’s unlikely.
How can you make randomness truly verifiable without relying on a slow blockchain?
Is there a way to combine player input, server input, and public entropy to make it fully auditable?
And crucially, can this be done without killing real-time performance in a game?
I’m curious what people in production are doing — clever commit-reveal models, public beacon sources, hybrid systems?
I’d love to see practical approaches that actually remove trust entirely, not just add a “proof” that still requires faith.
Let’s talk solutions.
0 comments
—
Ask HN: Are "provably fair" JavaScript games trustless? · HackerTrans
Everyone talks about “provably fair” games, raffles, and loot boxes — but in practice, most implementations still require players to trust the server.
Think about it: the server commits a seed, the player sees a hash, and after the game, the result is revealed. Technically, the house could precompute outcomes and cherry-pick them — even if it’s unlikely.
How can you make randomness truly verifiable without relying on a slow blockchain?
Is there a way to combine player input, server input, and public entropy to make it fully auditable?
And crucially, can this be done without killing real-time performance in a game?
I’m curious what people in production are doing — clever commit-reveal models, public beacon sources, hybrid systems? I’d love to see practical approaches that actually remove trust entirely, not just add a “proof” that still requires faith.
Let’s talk solutions.