What Entropy Actually Is, and Why 128 Bits Matters

The one sentence version

Entropy is a count of how many equally-likely outcomes a process could have produced, expressed as a power of two — and because everything in a Bitcoin wallet is derived from one random starting number using public math, that count is your security, entirely and exclusively.

Everything else on this page is unpacking that sentence, because almost every catastrophic wallet failure in Bitcoin’s history has been a failure of that one number rather than a failure of the cryptography built on top of it.

What a “bit” of entropy actually counts

One bit means two equally-likely outcomes. Two bits, four. Ten bits, 1,024. Each additional bit doubles the number of possibilities an attacker has to work through.

That doubling is the whole story, and it is why people’s intuition fails here. Going from 40 bits to 128 does not feel like it should be a big change — it is only about three times the number. It is in fact 2⁸⁸ times more work, which is roughly 310,000,000,000,000,000,000,000,000 times harder. Human intuition simply does not do exponents, which is exactly why a wallet can be catastrophically broken and look completely normal.

Entropy is a property of the process, not of the number

This is the idea everything else depends on, and it is the one most people never quite absorb.

Take the number 7391056284. How much entropy does it have? The question is unanswerable as asked. If it came from ten fair rolls of a ten-sided die, it carries about 33 bits. If it is the last ten digits of a phone number in a public directory, it carries close to zero. The digits on the page are identical. The entropy is not a property of the digits — it is a property of how the digits came to be, and specifically of how many other digit sequences were equally likely to have appeared instead.

Apply that to a seed phrase and the consequence is stark. Twenty-four English words from the BIP-39 list look exactly the same whether they were derived from 256 bits of genuine physical randomness or from a broken generator with forty bits of real variation behind it. You cannot look at a seed phrase and tell. Neither can your wallet. Neither can any test that examines only the output. The only way to know is to know how it was made.

The ladder: 40, 72, 128, 256

Bits	Possibilities	Standing
40	~1.1 × 1012 (1.1 trillion)	Broken today. About 140 possibilities for every human being alive. Enumerable on ordinary equipment.
72	~4.7 × 1021	Broken by anyone motivated. Sounds huge; is 256 — about 72 quadrillion times — easier than 128.
128	~3.4 × 1038	The floor. Not “quite good”. This is the minimum a serious system is designed to.
256	~1.16 × 1077	Margin far beyond need. Within a few orders of magnitude of the number of atoms in the observable universe (~1080).

A mining-flavoured way to feel the numbers

Our readers mostly own hashing hardware, so here is a comparison in units you already have a feel for. The Bitcoin network’s hashrate is on the order of 10²¹ hashes per second. Suppose you could point all of it at counting through possibilities:

• 40 bits — about one nanosecond of network hashrate.
• 72 bits — about five seconds.
• 128 bits — roughly eleven billion years, which is comparable to the age of the universe.
• 256 bits — a number of years with forty-eight digits in it. There is no analogy; the point is that it is over.

Why the honest version of that comparison makes 128 look even better

That comparison is deliberately unfair, and we would rather say so than let someone else point it out. One SHA-256 hash and one candidate seed are not the same unit of work. Turning a candidate into an address means running PBKDF2-HMAC-SHA512 for 2,048 iterations, then elliptic-curve key derivation, then hashing to an address, then checking the blockchain. A single seed candidate costs thousands of times more than a single mining hash.

So the numbers above are a feel for scale, not a cost estimate. And correcting for it only strengthens the conclusion at both ends: 128 bits gets even more comfortably impossible, while 40 bits stays trivially cheap — because 1.1 trillion candidates is small enough that the extra cost per candidate does not save you. We do not have to model it, either. In the Coldcard incident that number was measured: CoinDesk reported a single observed sweep clearing roughly 500 wallets in a 25-to-41 minute window.

Where the 128 comes from: how BIP-39 is built

12 words, 24 words, and the checksum

A BIP-39 seed phrase is a readable encoding of a random number, nothing more. The construction:

• The wordlist holds exactly 2,048 words, and 2,048 = 2¹¹. Each word therefore carries exactly 11 bits.
• A 12-word phrase carries 12 × 11 = 132 bits — which is 128 bits of entropy plus a 4-bit checksum.
• A 24-word phrase carries 24 × 11 = 264 bits — 256 bits of entropy plus an 8-bit checksum.

The checksum is a typo detector, not security. It is derived from the entropy, so it adds no unpredictability — it just means a phrase with a transcription error will usually be rejected rather than silently opening an empty wallet.

Note what this means: the 128-bit figure is baked into the format. A 12-word phrase always encodes 128 bits. Whether those 128 bits were actually 128 bits’ worth of randomness when they were generated is a completely separate question that the format cannot answer, does not check, and has no way of knowing. Every affected Coldcard produced a perfectly valid, correctly-checksummed BIP-39 phrase.

Why 24 words is not “twice as safe” in any way that matters

Doubling from 128 to 256 bits doubles a number that was already unreachable. Neither is getting brute-forced. Choosing 24 words is reasonable for a long-horizon margin, but if you are picking 24 because you believe 12 is insufficient, the belief is misplaced — and the effort is far better spent on making sure the randomness behind whichever length you pick was real. See also our glossary entry on Seed Phrase.

Dice: the arithmetic you can check yourself

A fair six-sided die produces one of six equally-likely outcomes. In bits, that is log₂(6) = 2.585 bits per roll. Coldcard’s own documentation uses precisely this figure.

Why 50 rolls and why 99

• 128 ÷ 2.585 = 49.5, so 50 rolls is the minimum for 128 bits. Fifty rolls give 129.25 bits.
• 256 ÷ 2.585 = 99.04, so 99 rolls is the conventional figure for 256 bits.

These are not arbitrary. Both Coldcard and SeedSigner enforce exactly 50 rolls for a 12-word seed and 99 for a 24-word seed, and Coinkite’s advisory for the 2026 entropy incident uses “at least 50 fair and independent rolls” as the threshold at which a seed is not considered at risk from that flaw. Fifty rolls of a physical die was, in the end, the mitigation that held.

The 99-roll rounding nobody mentions

Here is the pedantic truth, stated because we would rather be right than tidy: 99 rolls is 255.91 bits, not 256. It falls about a tenth of a bit short. Reaching a genuine 256 requires 100 rolls (258.5 bits).

Does it matter? No — not remotely. A tenth of a bit at the 256-bit level is a rounding error on a number that is already unreachable, and both implementations hash the rolls into a full-width value regardless. But we are stating it because a page about entropy that quietly rounds its own numbers up has undermined its own subject. If you want the clean version: 50 rolls genuinely exceeds 128; 99 rolls is a hair under 256; roll 100 if it bothers you.

Coins, if you have no dice

A fair coin flip is exactly one bit — the cleanest possible source, and unlike a die a coin has no manufacturing bias worth worrying about. The cost is volume: 128 flips for a 12-word seed, 256 flips for 24 words. SeedSigner’s verification tooling accepts coin flips at exactly those counts.

How a random number generator fails silently

This is the part that matters most, and it is the part almost never explained.

Randomness tests measure the shape of the output, not the size of the input

Suppose you feed a well-designed pseudorandom generator a starting value of only 40 bits, then ask it for a megabyte of output. Run every statistical randomness test ever written against that megabyte — frequency, runs, spectral, compression, the lot. It passes all of them. The output has the right shape in every measurable respect. It is uniformly distributed, uncorrelated, incompressible.

It is also completely predictable to anyone willing to try all 2⁴⁰ starting values.

That is the whole trap in one paragraph. Randomness tests measure the shape of the stream. Security depends on the size of the secret that produced it. A generator can be perfect at the first and catastrophic at the second, and no amount of testing the output will ever reveal it. This is not a flaw in the tests — it is a fact about what they can possibly measure.

The four properties that make these bugs survive for years

1. No visible symptom. The device works. The words look fine. The addresses are valid. Transactions sign and confirm. Nothing anywhere is wrong from the outside.
2. No self-test can catch it. For a device to detect that its randomness is weak, it would need a trustworthy independent source to compare against — and if it had one, it would have used it in the first place. A device cannot audit its own ignorance.
3. The defences are compile-time and one character wide. The correct place to catch this is a build-time check that refuses to compile if the wrong source is selected. In the Coldcard case such a check existed and was written as #ifndef (“if not defined”) when the intended meaning was “if not enabled”. The flag was defined — and set to zero. Coinkite’s own backgrounder states it: “We defined that macro as zero, so the #error did not stop the build.” One preprocessor directive between correct and catastrophic, with no runtime symptom on either side.
4. The damage is retroactive and permanent. Patch the generator and every future seed is fine. Every seed already produced stays weak forever, because the seed is the wallet. This is the property that makes entropy bugs uniquely bad: unlike almost any other class of vulnerability, fixing it does not help the people it already hit.

Two real cases

Milk Sad (2023). Libbitcoin Explorer versions 3.0.0 through 3.6.0 used a Mersenne Twister generator seeded with only 32 bits of system time. Wallets were actively drained. Catalogued as CVE-2023-39910, published 2023-08-09.

Coldcard (2026). A build-flag regression introduced on 2021-03-01 caused seed generation to use a software fallback generator rather than the hardware source, for five years and four months. Coinkite disclosed it on 2026-07-30 and patched it the following day. Effective randomness was around 40 bits on Mk2/Mk3 and around 72 bits on Mk4/Mk5/Q. Galaxy Research attributes roughly 1,596 BTC — over 100 million US dollars — to the flaw with high confidence as of 2026-08-04. Full detail and the affected-version table: our Coldcard advisory.

Different projects, different decades, different languages. Same shape: a fallback path that was never supposed to run in production, ran in production, and nothing looked wrong.

What actually protects you

Not much, honestly, and that is worth saying plainly rather than ending on a comfortable note.

You cannot inspect a seed and learn its entropy — that is not a limitation of your tools, it is a property of the mathematics. You cannot test the output. You cannot rely on the device to know. What you can do is narrow:

• Supply the randomness yourself, physically, and use a method where you can recompute the result independently and confirm it matches. This is the only approach that converts trust into verification. It is the subject of our companion guide: how to verify your own seed entropy without trusting the device.
• Spread the trust across vendors so that any single vendor’s mistake is survivable rather than fatal — the argument for multisig across different manufacturers.
• Know what your device actually does. Which randomness source, whether you can add your own, whether the result is reproducible. Our Bitcoin Signing Devices Reference and Wallet Sovereignty Matrix exist for this.

None of that is a guarantee, and anyone selling you a guarantee is selling. But “verify rather than trust” is not a slogan here — it is the only available response to a class of failure that is, by construction, invisible.

Sources

• BIP-39 specification — bitcoin/bips
• Coldcard, “Verifying Dice Roll Math” (2.585 bits per roll; 50 / 99 roll minimums; SHA-256 over the ASCII roll string) — coldcard.com/docs/verifying-dice-roll-math
• Coinkite technical backgrounder (the #ifndef guard; effective-entropy figures) — blog.coinkite.com/entropy-technical-backgrounder
• Coinkite advisory — blog.coinkite.com/coldcard-mk3-seed-generation-warning
• Block engineering analysis — engineering.block.xyz
• Wizardsardine, brute-force feasibility — wizardsardine.com
• Milk Sad / CVE-2023-39910 — GitHub Security Advisories
• SeedSigner dice verification documentation — github.com/SeedSigner/seedsigner
• CoinDesk, observed sweep timing — coindesk.com