Understanding entropy in Bitcoin seed generation

Entropy is measured relative to what an attacker knows — not relative to what other people do.

This is the most misunderstood point in the whole subject. Entropy is not a property of your ritual, your equipment, or how unusual your method is. It measures how many equally likely outcomes your process could have produced, from the perspective of someone who knows your entire procedure in complete detail.

An attacker does not guess your method. They guess your outcomes.

This is why "nobody else shakes dice in a jam jar the way I do" adds exactly zero bits. It is security through obscurity. Two people rolling fair dice each get the full amount of entropy and land on different seeds. Neither one is "more random" than the other.

Entropy is counted in bits. Each bit doubles the number of possible outcomes.

The formula is log2(outcomes). A d6 gives log2(6) ≈ 2.585 bits.

This is a hard ceiling. It is set by the number of faces, not by how vigorously you throw. No cup, container, surface, or technique can push a d6 above 2.585 bits per roll.

Technique determines only whether you reach the ceiling or fall short of it. That reframing answers almost every "does this make it more random?" question before it is asked.

How many rolls?

99 rolls gives 6^99 ≈ 2^255.9 — a whisker under 256, which is why 99 is the stated minimum for a 24-word seed.

All of these have the same answer. They do not add entropy; they only affect whether you hit the ceiling.

Containing the dice so they can't roll away

Fine, and standard practice. What matters is the bounce count. A die that tumbles and ricochets several times before settling is chaotically unpredictable, and that is all you need.

Containment only hurts in the degenerate case: a slot or tube so tight the die slides rather than tumbles, so where it lands correlates with how you dropped it. If it rattles freely, you are at the ceiling. That is the whole test.

Using a cup to shake them

Mildly helpful. A cup usually increases tumbling and decouples the outcome from your hand motion. It does not add entropy — nothing does — it just makes it more likely you are at the ceiling. A cup where the dice rattle audibly is doing its job.

The rolling surface

Hard and flat beats soft. This surprises people, but it follows directly: hard surfaces produce more bounces and more tumbling. Felt, cloth, or a towel damps energy fast, so a die can settle after very few tumbles — and soft or uneven surfaces produce more cocked dice, which means more ambiguous judgment calls.

Rolling more than one dice at a time

Works, with one important fix: use different-coloured dice as opposed to trying to record left to right or similar and record red-then-blue for example.

Position-based ordering breaks down exactly when the dice land ambiguously — stacked, diagonal, touching, or one cocked against the other. At that moment you are making a judgment call, and human judgment calls are not uniform.

Minor purist note: two dice thrown together can collide, which technically couples their outcomes very slightly. The effect is negligible, but rolling a single die repeatedly avoids the question entirely.

If you re-roll because "three 6s in a row doesn't look random enough", you have just injected your intuitions about randomness into your seed. Human intuition about randomness is famously poor and highly predictable, and this single mistake can destroy far more entropy than any equipment flaw.

Real 100-roll sequences contain runs. Long runs are expected. Keep them.

Two standard methods. They produce different results from the same rolls, so pick one and stay consistent — mismatching them is the most common cause of "my words don't match" confusion.

Method A — base-6 digits

Treat the rolls as digits of a base-6 number. Map 6 → 0 and leave 1–5 as themselves. Used by SeedSigner: 50 rolls for 12 words, 99 for 24.

Method B — hash the roll string

Concatenate the digits into one long string and run SHA-256 over it to get 256 bits. Used by Coldcard. This is the more forgiving option, for reasons covered next.

Cheap pipped dice have material drilled out for each pip, so the 6 face is fractionally lighter than the 1 face. The real-world skew is a fraction of a percent, costing a negligible fraction of a bit across 256. Casino dice have flush, filled pips and remove the question for a few dollars.

Rolling several dice at once does not cancel out bias. Each die still carries its own.

You can collect more than 256 bits of input. You cannot have a BIP39 seed with more than 256 bits of output — and you would not want one.

The numbers

• 99 rolls = 255.9 bits of raw input
• 128 rolls = 331 bits of raw input
• SHA-256 compresses whatever you feed it to exactly 256 bits

Past a comfortable surplus, extra rolls buy nothing. A thousand rolls into SHA-256 gives the same 256-bit output as 128 rolls.

Why the ceiling exists

24 words is the top of BIP39: 256 bits of entropy plus an 8-bit checksum = 264 bits = 24 × 11. There is no 30-word option.

And the ceiling is not arbitrary. A Bitcoin private key is a number below the secp256k1 curve order, which sits just under 2²⁵⁶ — a key literally cannot hold more than 256 bits.

Further: the best known attack on the discrete log problem is Pollard's rho, which runs in roughly the square root of the key space. That puts the real security level of any secp256k1 key at about 128 bits, regardless of how much entropy went into the seed.

Which means a 12-word mnemonic already saturates Bitcoin's security: 128 bits of entropy against a 128-bit security level. The honest case for 24 words is margin against a partially broken RNG or a future cryptanalytic dent — not against brute force.

If you genuinely want more secret material

Three legitimate routes, none of which is "a bigger seed".

• BIP39 passphrase. The mnemonic and passphrase both feed into PBKDF2, so an attacker holding your 24 words still faces the passphrase. A genuine second factor. Caveat: a forgotten passphrase is unrecoverable loss, with no error message — just an empty wallet.
• Multisig. A 2-of-3 with three independent seeds means an attacker needs two separate compromises. A different threat model, and in practice far more valuable than extra entropy.
• XOR two independent sources. Take your 256 dice bits and XOR them with 256 bits from a system CSPRNG. The output is still 256 bits, but it is secure if either source is good. Loaded dice? The system RNG saves you. Backdoored RNG? The dice save you.

That last one is usually what people actually want. The anxiety behind "can I get more than 256 bits" is nearly always "what if my entropy source is bad" — and the fix for that is independence, not quantity.

You cannot verify entropy statistically. You can decode a mnemonic back to its 128 or 256 raw bits, but running ent or dieharder on 32 bytes is meaningless — randomness tests need megabytes to say anything. A perfectly good seed will "fail" and a backdoored one will "pass". Don't bother.

What you can verify is that the encoding and derivation are correct: that your entropy maps to those words, and those words map to those addresses.

The method

1. Reproduce the result in a second, independent implementation — python-mnemonic, an offline copy of the Ian Coleman BIP39 tool, or a separate device.
2. Compare all four of: master fingerprint, account xpub or zpub, first five receive addresses, first five change addresses.
3. If all four match across two independent implementations, the derivation is correct.

Test with throwaway data, never your real seed

Verification only tells you whether two implementations agree. A decoy seed proves that exactly as well as your real one — so never type a funded seed into a browser.

• Best option: use the published BIP39 test vector abandon × 11 followed by about. It is in the spec, everyone knows it, and nothing is leaked by typing it anywhere.
• Or: generate a disposable mnemonic, verify with it, then delete it. Write "DECOY — DO NOT FUND" beside it. Once typed into a browser, treat it as permanently compromised.

Coldcard's own documentation follows this logic: verify the dice-roll maths with a few throwaway rolls, not with your real ones.

If you must check the real thing offline

Only worth it if you generated the entropy yourself and want to confirm your own dice-to-words arithmetic.

1. Download bip39-standalone.html and verify its SHA-256 against the published hash
2. Transfer by USB to an air-gapped machine — Tails is ideal, since it forgets everything on shutdown
3. Physically disable networking, open via file://, work offline, power off

Tick Show entropy details, set the mnemonic length first, then enter your data. Enter dice rolls as Hex rather than the tool's dice format — the dice mode maps a roll of 6 to 0, and that mismatch is the classic source of confusion.

Ranked by real-world impact. Note that dice-throwing physics does not appear until the very bottom.