Dice Roll Entropy

An ideal fair six-sided die provides log2(6) ≈ 2.585 bits per independent roll. Fifty rolls therefore provide about 129.25 bits of input entropy, 99 about 255.91 and 100 about 258.50. COLDCARD specifies 99 rolls for a practical 256-bit target; the exact total is slightly below 256. Roll count does not prove the quality of real dice or guarantee a perfectly uniform hash output. [COLDCARD — Verifying Seed Mixing] [RFC 4086 — Randomness Requirements for Security]

For one roll, a conservative measure is min-entropy Hmin=−log2(pmax), where pmax is the probability of the most common face. If one face has probability 1/2, that is only 1 bit, not 2.585. Adding across rolls requires appropriate independence; repeating the previous outcome adds no further independent information. An observer who knows the entire sequence gains no secret randomness from it. [NIST SP 800-90B — Entropy Sources for Random Bit Generation]

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. [RFC 4086 — Randomness Requirements for Security]

In Dice Rolls Only mode, COLDCARD documentation computes SHA-256 over the ASCII digit sequence. 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. [COLDCARD — Verifying Seed Mixing] [RFC 4086 — Randomness Requirements for Security]

COLDCARD documentation revised on September 6, 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. [COLDCARD — Verifying Seed Mixing]

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. [BIP 39 — Mnemonic code for generating deterministic keys]

Reproducing a public test vector checks agreement of encoding, hashing and conversion, not the fairness of dice or every device. Even a statistically attractive short sequence does not prove cryptographic unpredictability. NIST SP800-90B distinguishes source modeling, min-entropy estimation and health tests; a home roll count is not certification under that standard. Invented numbers or repeated patterns do not replace physical randomness. [RFC 4086 — Randomness Requirements for Security] [NIST SP 800-90B — Entropy Sources for Random Bit Generation]

In a dice-only mode, the complete record or final hash can reconstruct the wallet; mixing also makes device inputs sensitive. Verify with a disposable test set that you never fund, then use fresh private inputs for the real wallet. Photographs, clipboard contents and logs can preserve secrets. Back up the resulting Seed Phrase and any passphrase according to the chosen format and verify recovery. [COLDCARD — Verifying Seed Mixing] [BIP 39 — Mnemonic code for generating deterministic keys]