Knowledge Base

Overview

A public randomness beacon is a service that periodically emits random values which anyone can observe, that no single party can predict or influence in advance, and that anyone can independently verify after the fact. Public randomness solves a trust problem: a private random number generator asks you to trust that its output was fair, while a public beacon draws its randomness from events out in the open that nobody controls. That property matters wherever fairness must be demonstrable rather than assumed, such as lotteries, random selection, sortition, and leader election. Truestamp captures values from three independent public randomness sources and folds them into its evidence so that its records inherit the same unpredictable, publicly checkable character.

Security properties of a good beacon

A randomness beacon is only useful if its outputs are hard to game. The literature on public randomness converges on a small set of properties that a trustworthy beacon should satisfy, and they are worth defining precisely because each one closes a different attack.

• Unpredictability. Nobody can compute or narrow down a future beacon value ahead of time. An adversary who has watched every past value still cannot predict the next one. This is what lets a beacon value act as a proof that some data was chosen or submitted after the value existed, rather than before.
• Bias-resistance (unbiasability). No participant, including the beacon operator, can nudge the output toward a preferred result, and no participant can selectively abort to re-roll an unfavorable one. The output distribution stays uniform regardless of who is watching or wants what.
• Public verifiability. Anyone can check, from public data alone, that a published value was produced correctly. Verification does not require trusting the operator or holding a secret.
• Availability. Values are produced on a predictable cadence and remain publicly accessible, so a consumer can always obtain the value it needs.

These are conceptual properties of the randomness sources themselves. How strongly any particular source delivers them depends on the source: a proof-of-work chain earns unpredictability from the cost of finding a block, while a signed government beacon earns it from a keyed construction. External research on beacon design is listed under Citations.

Unpredictability and the submitted-after edge

The most useful consequence of unpredictability is that a beacon value doubles as an earliest-possible time. Because a value cannot be known before it is published, any data that incorporates that value must have been assembled afterward. This is the cryptographic version of the classic “proof of life” trick, where a person holds up a current newspaper: the newspaper carries information that could not have been known in advance, so the photo must be recent. A beacon value plays the newspaper’s role, except it is machine-verifiable and cannot be forged.

Truestamp uses this to prove submission timing. A record whose fingerprint commits to a captured beacon value is proven to have been submitted after that value was published, and that is the submitted-after edge of its submission window. The submitted-before edge is closed by different evidence: a public blockchain transaction that commits to the Truestamp block holding the record, whose own published time is the edge. Together the two edges are a proof about the submission window, not about when the underlying data was first authored. For the timing guarantee in full, see the submission window, and for the boundaries of what that proof does and does not establish, see what Truestamp does not prove.

How Truestamp uses public randomness

Truestamp does not run its own beacon from scratch. Instead it observes values from three independent public randomness sources and records each observation. The three source families are a government-operated randomness beacon that publishes signed pulses, a distributed consensus ledger, and a proof-of-work blockchain. Each observation stores the identifying values the public source published, enough to look that record back up at the source, together with a hash computed over those captured values in a canonical form, so anyone who fetches the same public record can recompute the same hash.

Each observation is then put to work along two independent routes.

• Into a block. The observation is committed into a Truestamp block through inclusion in the block’s Merkle tree, which binds the observation to a specific point in the block history and makes the block itself evidence that everything in it was submitted after the captured value was published.
• Into an individual submission. At the moment a record is submitted, the newest captured observation from each source is committed into that record’s own fingerprint as a witness. The choice is fixed at submission and cannot be revised afterwards, and a proof can carry the captured payload itself, so a holder can rehash it, compare it against what the fingerprint committed to, and look the value up at its public source without needing the rest of the block.

Because the source values are unpredictable before they are published, and because the observations are recorded rather than invented, the evidence Truestamp produces inherits the beacon properties above. The individual sources and their capture behavior are covered by entropy sources, and the public page that surfaces Truestamp’s own beacon values is covered by public entropy beacons.

Public verifiability in practice

Public verifiability is not just a design goal for Truestamp; it is enforced by the data model. Entropy observations are public data. Anyone can read them, and each observation can be re-checked four ways:

• Recompute the hash from the captured values, in the same canonical form, and confirm it matches the stored hash.
• Check Truestamp’s own signature over the observation against the published signing keys.
• Check the observation’s Merkle proof against the Merkle root of the block that carries it.
• Compare the captured values against the original public source, for example a government beacon endpoint or a public block explorer.

None of these needs a secret or trust in Truestamp. Each rests only on public data and standard hashing and signature checking, which is exactly what public verifiability means.

Use cases

The value of a public beacon is that it lets mutually distrustful parties agree that an outcome was fair without a trusted referee. Common uses include:

• Fair lotteries and drawings. Announce in advance which future beacon value will decide the outcome, wait for it to be published, then derive the result from it. The organizer cannot rig a value that does not exist yet, and every participant can re-derive the result.
• Random selection and sortition. Assign people to groups, sample participants for a study, or pick an arbitrator, with a publicly checkable derivation instead of an unauditable coin flip.
• Leader election and coordination. Choose a coordinator or allocate a scarce resource in a way no participant can steer.
• Reproducible research. Publish the beacon value used so that a randomized procedure can be replayed and independently confirmed.

In every case the beacon’s unpredictability prevents manipulation before the fact, and its public verifiability lets anyone confirm fairness after the fact.

Limitations

A public beacon proves that a value existed and was unpredictable beforehand; it does not prove why a value was chosen or that a party incorporated it honestly into an unrelated decision. Truestamp’s evidence proves submission timing relative to committed values, not the creation time of the underlying data, and not authorship. The strength of the unpredictability guarantee is inherited from the underlying public sources, so it is only as strong as those sources collectively are; capturing from multiple independent families is a deliberate hedge against any single source weakening. Capture is best-effort and each source runs independently, so a source that has captured nothing by the time a record is submitted simply contributes no witness to that record rather than blocking it.

Citations

1. Wesolowski, Public Randomness Beacons (NIST Random Bit Generation Workshop, 2016). Frames the beacon security properties (unpredictability, public verifiability, unbiasability, availability) used above.
2. Lenstra and Wesolowski, A Random Zoo: Sloth, Unicorn, and Trx (IACR ePrint 2015/366). Discusses trustworthy generation of public random numbers and the delay-function constructions behind bias-resistance.
3. NIST Randomness Beacon. A government-operated public randomness service emitting cryptographically signed pulses at a fixed cadence, one of the public sources Truestamp observes.