Beacon-Seeded Fair-Sampling Deriver V2

Version 1 of this sampler is a proven, sealed node: it is not edited, and every receipt already issued against it keeps replaying byte-identically. New runs should use this V2 node, which fixes three V1 defects in a new algorithm id:

1. No draw cap. V1 rejected duplicate candidates against a walk capped at 10 × item_count draws; a full sample needs about item_count × H(item_count) draws (coupon collector), so near-full populations above roughly 12,000 items exhausted the cap and failed. V2 walks a partial Fisher-Yates over an index array: every accepted draw selects exactly one remaining item, so exactly sample_size accepted draws are consumed, at any population up to the 1,000,000-item ceiling (a 4 MB index array at maximum).
2. No modulo bias. V1 reduced each 32-bit draw with a raw remainder, which biases selection toward lower indices by up to item_count / 2³². V2 rejects any draw at or above the largest multiple of the remaining window width that fits in 32 bits, so every offset in the window is hit by exactly the same number of raw draws: exact uniformity, proven by integer arithmetic rather than statistics.
3. Validated hex inputs. Both hex inputs must now be exactly 64 lowercase hex characters (no sha256: prefix); anything else is a structured refusal naming the rule. V1 only trimmed them.

The emitted transcript is capped at 50 draws with full draws_used and rejection counts, so artifacts stay bounded at large sample sizes while the whole walk stays reconstructible offline from the declared inputs. For past receipts and replays of earlier samples, keep using ART-583 (version 1).

The fairness of this sample depends entirely on doing these three steps in order, before you touch this page:

1. Fix the population first. Freeze the exact item list to be sampled and hash it (any stable canonical hash of the manifest works; SHA-256 of the sorted item list is typical). Publish or otherwise commit to that item_manifest_hash (exactly 64 lowercase hex characters, no prefix) before the next step.
2. Wait for a beacon pulse you did not choose. Take the NEXT round of a public randomness beacon after your commitment: drand's quicknet chain (a new pulse roughly every 3 seconds, verifiable output published openly) or a NIST NISTIR-8213 randomness beacon pulse. Paste that round's declared randomness value below exactly as published (exactly 64 lowercase hex characters).
3. Derive, don't re-roll. This page derives the sample once, deterministically, from the manifest hash and the pulse. If the result is inconvenient, the correct response is never to re-run with a different pulse: that is the cherry-picking this ceremony exists to prevent.

Precedent: NIST's Interoperable Randomness Beacons project names bias-resistant audit sampling as a beacon application; U.S. election jurisdictions running risk-limiting audits (e.g. Colorado, per the U.S. Election Assistance Commission's RLA guidance) draw ballot samples from a public dice roll or beacon for the identical reason. drand quicknet is treated as the primary beacon here (sub-3-second cadence, no single operator); a NISTIR-8213 pulse serves as a corroborating co-seed when both are available.

Optional page-side check that drand's quicknet group actually signed the round you pasted above. The sampler itself never verifies signatures; this layer exists so a reviewer can confirm the pulse before trusting the sample. Paste the round number and the 48-byte signature (96 lowercase hex characters) from any drand API or relay, plus the declared round and randomness you fed the sampler. Everything runs offline in your browser against the pinned quicknet group public key; the page performs no network call of its own.

How the check works: the page hashes the round number (8-byte big-endian) with SHA-256, hashes that onto the BLS12-381 G1 curve with the RFC 9380 DST BLS_SIG_BLS12381G1_XMD:SHA-256_SSWU_RO_NUL_, and verifies the signature against the pinned quicknet group public key using vendored @noble/curves code (MIT, inlined below). Only after the signature verifies does the page derive randomness = SHA-256(signature), per drand's own definition, and compare it with your declared value. A pasted randomness value without a signature is refused: it is never evidence on its own.

What this proves, and what it cannot: the check proves drand's League of Entropy group signed this round. drand's own documentation states that linked drand nodes "collectively produce publicly verifiable, unbiased and unpredictable random values", which holds as long as a threshold of the independent drand operators behave honestly. The residual risk is therefore predictability if a threshold of drand operators collude, not bias. Fairness also requires the round to have been named in the plan before it existed: the manifest hash must be committed before the pulse round, exactly as the ceremony above requires. This check is page-side only: its result never enters the exported artifact, the node's policy_parameters, or the execution hash, and the derivation this page performs is unchanged.