# A fair choice starts before the random number. **Research note · 7 September 2026 · Bitcoin selection remains experimental.** A random value does not make a selection procedure fair by itself. The party operating the procedure might change the eligible set, reorder candidates, cancel an unfavorable request, or simply ask again. Every random value could be technically correct while the final selected result is biased. Proof21's Choice / Sample research therefore starts with the process around randomness, not with a promise that a Bitcoin nonce solves fairness. ## Commit what the outcome depends on Before a future source becomes known, the workflow should fix the candidate set, ordering, weights, sample size, request identifier, policy version, mapping algorithm, source, and confirmation conditions. The consumer needs evidence that this commitment existed at the required point in the sequence. A timestamp written by the operator into its own signed record does not independently establish that ordering. Commitment verification is its own problem. The lifecycle also needs explicit pending, failed, and completed states. A timeout should not silently switch to another source or permit another attempt whose result is more convenient. ## Bitcoin data has different jobs Height is predictable. The bits field encodes the proof-of-work target. Old block values are already public. Those facts make the fields useful for defined derivations, but not fresh unpredictability merely because a service hashes them. The Bitcoin header reference documents these field roles. [1] A future Bitcoin-dependent workflow introduces waiting and adversarial assumptions. The Bitcoin Beacon research analyzes the limitations of randomness built on Bitcoin. Established VRF integration guidance also stresses confirmations, fixed inputs, and avoiding rerolls or cancellations. [2][3] DMT derivation, historical replay, and future random selection are related capabilities with different guarantees. The consumer needs to know which one it is using. ## Audit sampling has two extra boundaries Suppose a marketplace commits a batch and samples some jobs for review. A reproducible sample proves something about selection from that batch. It does not establish that every eligible job was included in the batch. Completeness requires additional evidence. Likewise, selecting an auditor under an agreed procedure does not prove that auditor will perform a correct or honest evaluation. The evaluation itself needs checks. P21's proposed toolkit keeps selection and evaluation separate so neither becomes a vague “trust score.” ## The product hypothesis The interesting service is not “we sell a block field.” It is an inspectable workflow that makes the inputs, source, state transitions, and resulting selection portable between parties. A demonstration can be useful before it is safe for high-value deployment. It should show both a reproduced selection and rejection of an altered candidate set or changed policy. Production use must wait for a reviewed threat model and tested behavior, including aggregate incentives to influence a source shared across many jobs. ## Follow one selection from request to dispute Consider a synthetic marketplace selecting one reviewer from four eligible organizations. Before the selected source becomes available, the requester records the four stable identifiers in a specified order, the eligibility rule, any weights, and a unique operation identifier. A consumer should be able to reconstruct the same byte representation. A different ordering is a different input even if the displayed names look unchanged. The source event is selected by a rule, not by the operator browsing historical values until a preferred reviewer appears. The record should say how the source will be recognized, what confirmation condition applies, and what happens when the event is unavailable. This is a proposed lifecycle example, not an implemented Proof21 service or a recommendation for allocating valuable rewards with unreviewed Bitcoin randomness. After the source meets the agreed condition, deterministic code applies the named mapping algorithm. In a general implementation, simply taking a random integer modulo the candidate count can introduce bias when the integer range is not divisible by that count. A reviewed mapping can use rejection sampling: discard values outside a precisely defined usable range and derive subsequent values under a fixed procedure. That internal mapping step must not give the operator permission to request a different source because it dislikes the selected candidate. A dispute package should contain the committed inputs, evidence of commitment ordering, source identification, relevant observations, mapping version, and output. The consumer can then ask two distinct questions: does the output reproduce, and were the lifecycle rules satisfied? Reproduction of arithmetic alone answers only the first. ## Budget for the whole incentive, not one request A source may influence many selections at once. An adversary's possible benefit is not necessarily limited to one small job's advertised value. A threat model should identify all outcomes that depend on the same source, which parties can delay or suppress results, and whether unsuccessful attempts become visible. The Bitcoin Beacon paper supplies a useful research starting point for conditional assumptions; it does not certify this proposed product. [2] Operators also need a deliberate response to reorganizations and unavailable evidence. Keep the original request and mark its state. A replacement operation, when policy permits one, should refer to the earlier operation and explain its authorization. Hidden resets are precisely what a portable record is intended to expose. Neither a timestamp field nor a nicely animated wheel supplies that accountability. ## Tests that make the boundary visible A useful test suite starts with known inputs and a reproducible output, then changes candidate ordering, a weight, the source event, and the mapping version separately. It rejects reuse of another operation's result and detects an unsupported or late commitment. It also checks an unavailable source, an interrupted run, and a reorganization that invalidates the previous observation policy. For a pilot, measure how often consumers can independently reproduce an outcome and how often they receive a clearly explained unresolved result. Avoid a target that rewards operators for converting every timeout into apparent success. Proof21's offline demonstration is useful for teaching limited deterministic behavior with fixtures; it is not a live randomness beacon or evidence that these production lifecycle tests have all been implemented. ## Frequently asked questions ### Is a Bitcoin nonce a free, perfectly fair random number? No. A field's existence in a block does not eliminate source-influence, timing, or economic assumptions. Historical values are already known, and future Bitcoin-dependent selection needs an explicit threat model and confirmation policy. [1][2] ### Is replaying a selection the same as making a new selection? No. Replay recomputes the recorded operation from its original inputs. A new operation changes the decision context and can become a reroll. The application must retain the relationship and require the appropriate authorization. ### Can a fair selection prove the chosen reviewer is honest? No. It can address how a reviewer was selected under a specific procedure. Conflicts of interest, evaluation quality, evidence completeness, and authorization for the next action remain separate questions. ## Read further - [P21 Choice and Sample](https://proof21.xyz/docs/capabilities/choice/) - [Selection lifecycle diagrams](https://proof21.xyz/diagrams/) - [1: Bitcoin block headers](https://developer.bitcoin.org/reference/block_chain.html) - [2: Bitcoin Beacon](https://arxiv.org/abs/1605.04559) - [3: VRF security considerations](https://docs.chain.link/vrf/v2-5/security)