150 / 736DICE

Dice Roll Entropy

Wallet entropy from physical dice rolls

Dice can supply randomness for a new wallet. The roll count is only part of the story: results must be genuinely random, remain private and be converted correctly into wallet data.

Dice Roll Entropy is a way to obtain unpredictable input for a new wallet by physically rolling dice. A wallet is an application or device for receiving and sending bitcoin. Private keys are secret numbers that let you authorize spending bitcoin. Imagine Anna: rather than inventing numbers, she feeds the results in their exact order into a verified offline procedure. Those data become the basis for the keys to her bitcoin. Entropy here measures the uncertainty faced by someone who does not know the results and tries to guess them. Dice help only if the rolls are sufficient, independent and private. More recovery words or a long digital fingerprint cannot rescue weak or published input. The calculations below explain why; they are not an invitation to build your own generator.

A bit is a unit of information. With equally likely possibilities, each additional bit doubles the number of possibilities an attacker must choose between. It is not another dot on the die or another backup word. A fair six-sided die has six equally likely outcomes. Two independent rolls have 36 possible pairs. In bits, this is log2(6) ≈ 2.585 per roll. Under those ideal conditions, 50 rolls contain about 129.25 bits, 99 rolls 255.91, and 100 rolls 258.50. COLDCARD lists 99 rolls for a practical 256-bit target; mathematically that is slightly below 256. Counting rolls alone does not validate the die or guarantee a perfectly uniform conversion result. [1] [3] [5]

If one face occurs more often, the attacker has a better guess. If the most likely face has probability 1/2, one roll provides only 1 bit of min-entropy. Min-entropy measures unpredictability by considering an attacker’s best single guess. The formula Hmin=−log2(pmax) uses the probability of the most likely outcome, called pmax. Adding the values across rolls requires the appropriate independence. Copying the last result does not replace a new independent roll. Anyone who knows the whole sequence need not guess it at all. [4]

For a wallet made only from rolls, the complete sequence or resulting hash, a digital fingerprint calculated from those data, may be enough to recreate it. With mixing, device inputs are sensitive too. Do not enter real rolls into an online checker or photograph them. Check the calculation using a separate test wallet that you never fund; use fresh private inputs for the real one. Clipboards and logs may retain the data. Keep the resulting Seed Phrase, a backup written as words, safe and test recovery. If you also use a passphrase, an additional secret that selects a different wallet from the same words, you need that for recovery too. [1] [2]

Matching a public test example checks encoding, hashing and conversion. It does not prove that your die or device works correctly. A short sequence that looks good does not prove unpredictability either. NIST SP800-90B distinguishes a source model, min-entropy estimation and checks that the source is functioning. A series of rolls at home is not certification under that standard; invented numbers or a repeated pattern do not replace physical rolls. [3] [4]

ASCII specifies how digits are represented for a computer; newline means a line-ending character. Exact spelling matters because the computer processes the supplied characters, not their human meaning. According to its documentation, COLDCARD computes SHA-256 over the ASCII digit sequence in Dice Rolls Only mode. Public test 123456 without a trailing newline hashes to 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92. Six ideal random rolls would carry only about 15.51 bits; this published sequence is not secret at all. A 256-bit output adds no missing entropy; a different input encoding can produce a different result. [1] [3]

In the following formula, d1 and d2 are the first and second roll results. The mod operation means the remainder after division. Two preimages means that two different original values lead to the same result, giving that result a greater chance. As a teaching example, encode two fair independent rolls as x=6*(d1−1)+(d2−1), from 0 to 35. Taking x mod32 favors 0 through 3 because each has two preimages. Rejection Sampling instead discards 32 through 35 and repeats the pair; accepted values 0 through 31 provide five uniform bits. This explains a conversion error, not a procedure to replace a verified wallet generator. [3]

COLDCARD documentation revised on October 1, 2026 distinguishes Dice Rolls Only without hardware randomness from standard generation that mixes the device value with physical dice rolls or coin flips. The verify_seed_mix.py tool checks the latter mode; rolls.py and rolls12.py check the former. Rolls alone cannot establish a match when the input also contains the device value; select the exact procedure and firmware version. [1]

BIP39 describes how input bits become recovery words and how those words are then used to derive a seed, the starting data for keys. A checksum helps detect some transcription errors; a passphrase is an optional additional secret. The final algorithm named below computes the seed from the words and passphrase. BIP39 appends four checksum bits to 128 input bits and divides the resulting 132 into 12 groups of 11 bits; 256 input bits plus eight check bits produce 24 words. The checksum is derived and adds no randomness. Subsequent PBKDF2-HMAC-SHA512 produces a 512-bit seed from the phrase and passphrase, but the length 512 alone does not strengthen weak rolls. Word format, input entropy and derived seed are different layers. [2]

For the clearest picture, read this entry together with Cryptographic Entropy, Entropy Bit, BIP 39, Seed Phrase, Entropy Mixing, CSPRNG. The reverse links also lead from Cryptographic Entropy, COLDCARD RNG Incident (2026).

DOC · 001COLDCARD — Verifying Seed MixingDocumentation DOC · 002BIP 39 — Mnemonic code for generating deterministic keysSpecification DOC · 003RFC 4086 — Randomness Requirements for SecuritySpecification DOC · 004NIST SP 800-90B — Entropy Sources for Random Bit GenerationSpecification DOC · 005Bitcoin Developer Guide — WalletsDocumentation
Revised: Source-first · No investment advice