What Is Entropy? A Plain-Language Guide to How Your Bitcoin Keys Get Made
The Coldcard entropy bug has triggered a lot of Bitcoiners to ask a fundamental question that has been taken for granted. People who have used a single hardware wallet for years are wondering how they can be sure their own keys are random.
Entropy is the word behind all of it: what does it mean, what breaks when it fails, and how many “dice rolls” solve the problem?
Entropy in the real world
A casino invests significant money making sure a shuffled deck or a spinning roulette wheel can't be predicted. The moment either one is even slightly biased, someone works out the pattern, and the house starts losing money on that table. A secure Bitcoin seed needs a source of randomness unpredictable enough that no one, not even a supercomputer, could guess the result.

Cloudflare at one point implemented a novel solution of creating entropy with roughly 100 lava lamps mounted on a wall, and a camera photographing them at regular intervals and sending the images to Cloudflare's servers. Every pixel in a digital image carries its own numerical value. Because the wax in a lava lamp never takes the same shape twice, each photo gives the servers a fresh string of unpredictable numbers to start from.

People walking through the lobby and blocking the camera's view add to the disorder rather than spoiling it. Cloudflare called it the Wall of Entropy.
Security people measure the unpredictability of entropy in bits. Each bit doubles the number of possibilities an attacker has to search. A standard Bitcoin seed is built to have 128 bits of entropy, a number large enough that guessing it by brute force isn't realistic with any computer that exists today or is likely to exist for a long time.
The Coldcard bug mattered because it cut that number down to somewhere between 32 and 72 bits, depending on the model. Each missing bit doesn't weaken the lock a little. It cuts the number of guesses an attacker needs in half.

How a device is supposed to generate entropy
Hardware wallets are built with a chip whose entire job is to produce true randomness, usually by measuring some physical process, like electrical noise, that no one can predict or replay. That output becomes your seed.
The Coldcard bug happened because a configuration mistake let a predictable, software-based substitute stand in for that chip instead. The device still produced a normal-looking seed phrase. The randomness behind it wasn't what it was supposed to be.

The failure mode for Coldcard wallets was a working chip that never got used because the path to it broke somewhere upstream. The next logical question hardware wallet users ask is how to verify a hardware wallet generated enough entropy.
There are a few ways check your entropy.
- Use a tool like bip39-cli’s analyze_entropy_quality function.
- Note: Do not enter any seed you intend to use into an internet-connected device
- Plug it into an agentic model to try to interpret and check how the entropy is generated
- Generate a few million / billion seed phrases and plug them into a NIST SP 800-22 test suite
For the everyday user, those options are neither practical nor reliable as they open up other potential failure or exposure opportunities.
The easiest and most secure way to make sure your digital assets are secured with enough entropy is to have them secured by multiple hardware devices in a multisig from different manufacturers, each generating their own entropy. If one wallet has bad entropy, that doesn’t mean that your assets are lost. It just means that you have to rotate out the compromised key from your multisig which takes about 5 minutes.
For advanced users who want to rely on their own entropy on top of a multisig wallet, one method skips the question by skipping the chip: rolling dice yourself.
How many dice rolls is enough
Dice circumvent the black box hardware entirely: you supply the randomness yourself, with no configuration flag that can quietly fail. The question becomes how many rolls it takes to reach the same 128-bit target a chip is built to hit. A standard six-sided die gives you about 2.585 bits of entropy per roll.
Hitting that number takes roughly 50 rolls: 50 times 2.585 comes to about 129 bits, slightly over the target. Jameson Lopp’s own guidance, and independent security researchers who reviewed this bug, both land on 50 rolls as the threshold for a seed that never touches the affected part of the firmware.
The rolls have to be private, independent, and from a fair die. Casino dice are generally accepted as the most fair dice to use for entropy generation. A die that's chipped or weighted, rolls done in front of someone else, or rolls restarted because the result seemed wrong all reduce the real entropy below what the count alone suggests.
Rolling the dice yourself only helps if the software turns those rolls into the seed you expect. A generator can take your rolls and still produce a seed you did not derive, either by falling back on its own entropy or by reading the sequence differently than you assume. The count of rolls tells you nothing about what the generator did with them.
You can check this before the seed protects anything. Record your sequence as you roll, then enter that identical sequence into a second, independent dice-to-seed implementation on an offline machine.
Set both tools to the same derivation path and compare the seed words and the first receive address. Matching output means both read your rolls the same way. Anything else means one of them is doing something you did not intend, so generate a fresh sequence before you fund anything.
Destroy the written record of the sequence once you have confirmed the match.
What this means if you're moving from a single-key wallet to multisig
Putting a wallet with weak entropy into a multisig does nothing to make that key's own entropy stronger. All a multisig wallet does is prevent that weak device or a single manufacturer's flaw from being enough on its own to move your funds. A seed that was already weak going into the vault stays weak.

Multisig's protection comes from the signature threshold itself. If your vault needs two of three keys to move funds, and one of the three is a Coldcard-generated seed at 32 bits of entropy instead of 128. An attacker who cracks that one key still can't move anything alone. They need a second signature, and if that second key came from a different, unaffected device, it still sits at the full 128 bits, exactly as hard to guess as before. The weak key makes one signature easy to obtain while the second signature stays as robust as it was meant to be.
That protection only holds if the two keys are independent of each other. If two of your three keys are Coldcards from the affected period, an attacker who can crack one has an opportunity at cracking the other the same way. The two-key threshold does not necessarily stop them if both keys share the same weakness.
A properly built multi-vendor multisignature vault means one bad key can't compromise the whole vault on its own and it doesn’t fix a weakly generated key.
What to ask about every key you own
Ask the same entropy question about every key in your vault, not just the one that made the news this week: where did this seed come from, and what generated its randomness. More importantly, ask yourself if you are relying on a single point of entropy. The Coldcard bug is the most visible recent example of what happens when that question goes unasked for years. The best way to mitigate entropy risk is as simple as securing your digital assets with a multi-vendor multisig vault.
If you're weighing a move from a single device into a multi-vendor multisig vault or want to talk through what this means for a specific Coldcard-originated or single hardware wallet key, book a no-obligation session with the Casa team.
