Random Beacon
Random Beacon (Version 3) produces a fresh pulse on a fixed schedule on the server. Each pulse mixes cryptographically secure random bytes from the operating system with short snapshots gathered from a wide variety of independent live public feeds, including seismic, adoption, observatory, weather, water, air, traffic, grid, transit, and satellite sources, through a bounded server-side refresh. Every pulse is chained to the one before it and digitally signed, and any visitor can verify that signature with the published public key.
The pulse is built by a background process, never during your page request, so opening or reloading the page only displays the latest already-built pulse and never makes the site do slow work on your behalf. The app does not show the underlying feed locations, private nonce, raw buffers, the signing private key, or source code. (The pulse counter is deliberately public: it is part of the signed record.)
How the Beacon Qualifies Data
- Sources are grouped into families (seismic, observatory, weather, and so on). For each pulse, the order in which a family's sources are tried is decided by a SHA-256 hash keyed with the private server nonce, so an outside observer cannot know which sources were consulted.
- Sources are fetched in small batches until three qualify per family; remaining sources are skipped and reported as not fetched.
- A fetched stream must supply at least 768 usable UTF-8 characters and must differ from that stream's previous fetch, compared by SHA-256 fingerprint, so frozen or cached data never contributes.
- A window position inside the stream is derived from the private nonce, the pulse counter, and the prior beacon digest. Three contiguous 256-character buffers are read there, and the stream qualifies only when all three buffers differ from one another.
- Only the second buffer from each qualifying stream enters the beacon calculation.
- Streams that are unreachable, too short, repeating, or unchanged since their prior fetch are reported as not used, with the reason.
- Because the operating system's secure random generator supplies the core entropy of every pulse, the beacon is always produced on schedule even if few or no feeds qualify; the feeds are supplementary mixing material, not the sole source of unpredictability.
How the Beacon Is Formed
- A background process generates one pulse on a fixed schedule, off the request path, so the site never fetches feeds or blocks while serving a page.
- The core of each pulse is a fresh block of cryptographically secure random bytes drawn from the operating system's secure random generator.
- Those bytes are combined by SHA-256 with the private server nonce, the pulse counter, the pulse timestamp, the previous beacon digest, each qualifying second buffer, and a summary of all fetch fingerprints, then hashed once more to form the 256-bit beacon digest.
- The digest is expanded to 256 output bytes by repeatedly hashing it together with a fixed context label and a block counter.
- The new digest is stored and chained into the next pulse, so every beacon is linked to the entire history before it.
- Each pulse is digitally signed with an ECDSA P-256 key over SHA-256, and the signature and the exact signed text are published with the pulse.
- The output is shown as language-selected UTF-8 characters, base 16, base 8, and base 2, and each representation reports its character length. The language choice only changes how the shared pulse bytes are displayed; it does not change the pulse.
How the Pulse Is Signed and Verified
- Every pulse publishes a canonical signed string of the form
RB|version|counter|timestamp|previous-digest|current-digest, its SHA-256 beacon digest, and an ECDSA P-256 signature over that string, encoded in base64.
- The server keeps the ECDSA private key in a protected server directory that is not web-accessible, encrypted at rest, and never transmits it. The matching public key (curve nistP256, with its X and Y coordinates) is published so anyone can check a pulse.
- To verify, confirm the ECDSA P-256 / SHA-256 signature over the UTF-8 bytes of the published signed string using the published public key, and confirm that each pulse's stated previous digest equals the prior pulse's digest to follow the chain.
- A valid signature proves the pulse was issued by this server and has not been altered; the chained digests prove the ordering and history cannot be rewritten after the fact.
Cryptographic Security Argument
- Fresh secure randomness anchors every pulse. Each pulse begins with bytes from the operating system's cryptographically secure random generator, so its unpredictability does not depend on the feeds and cannot be reconstructed by an observer who watches every public source.
- Outputs are one-way. Every ingredient passes through SHA-256 during digest formation, so a published beacon reveals nothing about the secure random bytes, the private nonce, or the feed contents, by the preimage resistance of SHA-256.
- Authenticated and publicly verifiable. The ECDSA P-256 signature lets anyone confirm a pulse genuinely came from this server and was not tampered with, using only the published public key.
- No repeats, and history accumulates. A strictly increasing counter guarantees every pulse hashes a distinct input, and chaining each digest into the next means present outputs inherit the accumulated unpredictability of all past pulses.
- No denial-of-service surface. Because pulses are produced by a scheduled background process and requests only read the latest signed pulse, repeatedly loading the page cannot make the server do slow work and cannot degrade the rest of the site.
Privacy and Transparency
The page reports which pseudonymous buffers qualified, which did not, why, and a source page link for each pseudonym.
It deliberately avoids showing raw feed URLs, raw source buffers, private state values, stack traces, or implementation code to the browser.
Prior Random Beacons