HN Showcase
Back to browse
Double blind entropy using Drand for verifiably fair randomness

Double blind entropy using Drand for verifiably fair randomness

by rishi_blockrand·Feb 12, 2026·21 points·16 comments
Visit ProjectView on HN

AI Analysis

●●SolidBig BrainWizardryNiche Gem

Double-blind randomness via player commit, server secret, time-locked Drand. Technically sound but niche.

Strengths
  • •Elegant three-way entropy scheme eliminates any single party's control over output.
  • •Drand time-lock prevents server/player cheating — math-verifiable, no trust required.
  • •Live demo with full transparency: shows commitment, reveal, and verification steps clearly.
Weaknesses
  • •Niche use case — most apps use simpler RNG; crypto gaming adoption still small.
  • •Drand dependency adds latency (10 sec demo); impractical for sub-second randomness needs.
  • •No clear advantage over existing commit-reveal schemes plus a trusted oracle for lower-latency use cases.
Category
Security
Target Audience

Crypto/gaming developers needing provably fair randomness; blockchain applications requiring trustless randomization.

Similar To

Chainlink VRF (but trustless) · Commit-reveal schemes (standard pattern) · Drand itself

Post Description

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.

Similar Projects