Coldcard's Seed Bug Leaves Old Bitcoin Wallets Exposed Even After a Firmware Update

If you generated a Bitcoin wallet on a Coldcard in the last few years, you might need to move your coins. Not update. Move.

Coldcard’s seed-generation bug means some wallets created on older firmware have fewer random bits than they should. The sting in the tail is simple: updating your device later does not fix a seed that was already created with weak randomness.

The fix is to regenerate and migrate. That sounds scary, but it’s doable if you follow a calm, methodical process. Let’s walk it through.

What actually broke in Coldcard’s RNG

Good Bitcoin wallets rely on high-quality randomness. If the random number generator goes sideways, your seed can be guessed with far fewer tries than intended. That is what happened here.

Coinkite’s security advisory says seeds produced on certain firmware had less entropy than advertised. For Mk4, Q and Mk5 units before the fixes, seeds had roughly 72 bits of entropy where 128 bits were expected. That is not a rounding error. It is a major shrink in the search space. And on Mk2/Mk3 devices running v4.0.1 through v4.1.9, users are only safe if they provided at least 50 independent dice rolls during setup. Otherwise the seed may be predictable. You can read their breakdown and the fixed versions to install in the official advisory. Coinkite

An independent write-up by Block’s engineering and security teams points to two technical issues: an RNG-integration regression on Mk2/Mk3 v4 that can leave ngu.random without cryptographic entropy, and a reseed path on current devices that effectively caps the output space to at most 2^32 candidates if the fallback state and call history are fixed. That is about 32 bits. Combine that with other weaknesses and you get a dangerous reduction in the real entropy feeding wallet generation. Block Engineering

Both teams also warned that exploitation was happening in the wild. That means this is not a whiteboard problem. If an attacker can narrow a target down to millions or billions of possible seeds instead of 2^128, the economics change fast. Block Engineering & Coinkite advisory

Who is exposed and how to tell in 5 minutes

Quick triage checklist

• Device and firmware at the time of seed generation is what matters. If you later updated, that does not fix the original seed.
• Mk2/Mk3 users: If your seed was created on firmware 4.0.1 through 4.1.9 and you did not input 50 or more dice rolls, treat it as exposed. Coinkite
• Mk4, Q, Mk5 users: Seeds created before the fixed releases also lost entropy. If you generated your seed before installing Mk4/Mk5 5.6.0 or Q 1.5.0Q, it needs migration. Coinkite
• Used a passphrase from day one? It may raise effective security, but do not assume safety without strong passphrase entropy and careful review.

Where to find the relevant info

• Check your setup notes. If you wrote down firmware versions when you created the seed, you are ahead.
• On-device, review system menu for firmware history if available. If you cannot recall, assume worst case and plan a migration.
• Wallet birthday: if you know roughly when you created it and it falls into the affected windows since March 2021, plan to rotate.

Pro tip: If you used dice and tracked the exact count, 50 or more independent six-sided rolls gives about 129 bits of entropy. Fewer than that means weaker security if the device RNG had issues.

Why a firmware update alone doesn’t save old wallets

Seeds are created once. If the device fed in low-quality randomness at that moment, the damage is baked in. Updating firmware later only improves future operations. Your old seed retains the original entropy, good or bad.

Coinkite is explicit on this point: installing a fixed release does not repair vulnerable seeds. The only way to restore proper security is to generate a new, high-entropy seed and move funds to addresses derived from it. Coinkite

This also explains why both Coinkite and Block urged action. Attackers do not care that your device is patched now if the address set they are targeting was born from a weak seed.

Safe migration plan: regenerate, verify, move

Step 1: Update the device before creating anything new

• Install the fixed firmware for your model: Mk2/Mk3 4.2.0, Mk4/Mk5 5.6.0, Q 1.5.0Q. Verify signatures as the vendor instructs. Coinkite
• Disconnect from untrusted computers. Use air-gapped workflows if possible.

Step 2: Generate a new seed with human entropy

• Enable dice-entry and add at least 50 independent six-sided rolls. More is fine. Record the roll string offline. Do not photograph.
• Optionally use a passphrase, but only if you will never forget it. A high-entropy passphrase helps, but losing it strands funds.
• Back up the BIP39 words, plus passphrase notation if used, on durable offline media. Consider a metal backup.

Step 3: Create a watch-only wallet

• Export xpubs or a descriptor from the new wallet and load them into your wallet software on a clean machine. This lets you generate receive addresses and monitor without exposing keys.

Step 4: Do a test migration

• Send a small amount from the old wallet to the new. Wait for confirmations. Validate on-chain in a block explorer you trust.
• Confirm the receiving address and path match what your new watch-only wallet shows. Avoid address reuse.

Step 5: Move the rest with coin control

• Consolidate UTXOs carefully. If privacy matters, split movements over time and use fresh addresses.
• Mind fees. The mempool can spike. If you can wait, target quieter windows or use a fee estimator.
• Prefer PSBT workflows. Verify outputs and change addresses on-device before signing.

Step 6: Decommission the old setup

• Once you verify all funds are moved, mark the old seed as retired. Do not reuse those addresses.
• Update any services that had whitelisted deposit addresses.

Moving slowly and double-checking everything is safer than rushing. A single wrong address copy can be worse than the original bug.

Dice rolls done right: reaching real 128-bit strength

Dice entry is your friend because it adds entropy the device cannot fake. Each six-sided roll contributes about 2.585 bits. That means 50 rolls land you at about 129 bits, which meets or exceeds the 128-bit target often used for 12-word BIP39 seeds. If you are making a 24-word seed, 50 rolls still significantly strengthens the pool.

Practical tips:

• Use a physical die you control. Not a phone app.
• Roll on a flat surface and read each value out loud to focus. Enter it slowly. No do-overs or cherry-picking lucky numbers.
• Write the sequence by hand as a checksum for yourself. Store that paper separately from the seed words. Never put it online.
• If a model supports combining dice with internal RNG, great. The point is your hand-supplied randomness makes the whole stronger even if the internal RNG later fails.

Pro tip: If you already used at least 50 dice rolls on a Mk2/Mk3 during the affected window, Coinkite’s note says that specific seed is not at risk. Still, confirm your count and consider a migration if you are unsure. Coinkite

Operational pitfalls when moving UTXOs

Privacy slip-ups

• Avoid merging all UTXOs in one giant sweep unless you do not care about clustering. Smaller, staggered moves reduce linkage.
• Do not reuse receive addresses. Derive a new one for every incoming transaction.

Fee and confirmation anxiety

• Use a reliable fee estimator. If the network is jammed, set realistic targets with Replace-By-Fee enabled.
• Wait for sufficient confirmations on each leg before moving more. One clean step at a time.

Device and firmware risks

• Only download firmware from official sources. Verify signatures. This is exactly when phishing thrives.
• Keep the device isolated from malware. Prefer air-gapped PSBTs over live USB connections to unknown hosts.

Backups and labeling

• Label the new seed backup with the creation date and model. If you use a passphrase, document the existence of one, not the phrase itself.
• Test your recovery by restoring to a second device or an emulator in offline mode before you move significant funds.

Alternatives and mitigations if you can’t move today

Sometimes you cannot rotate immediately. Maybe you need multisig coordination, or your signer is in another city. Here is what you can do short term while you plan the migration.

• Stop receiving to the old wallet. Freeze the address set.
• If you already used a truly strong passphrase since day one, that may raise the attack cost. Do not add a new passphrase to the existing seed and think it retroactively protects old UTXOs. It does not.
• Consider moving a portion to a new seed now, then phase the rest later. Partial rotation is better than none.
• If you run multisig, check whether all cosigners’ seeds were generated on safe firmware. One weak signer can compromise the set depending on threshold.

None of these are perfect substitutes for a fresh, high-entropy seed. They are just triage until you can complete a full move.

How this slipped through: testing gaps and takeaways for the industry

This was not a simple single-line bug. It involved how the RNG was integrated, seeded, and reseeded across models and firmware lines. Subtle interactions are easy to miss until someone stress tests the entropy end to end.

Block’s engineering post explains that an RNG fallback path and a 32-bit reseed on current devices could drastically limit the output space under certain conditions. On Mk2/Mk3 v4, ngu.random could end up with no cryptographic entropy at all. That speaks to the need for fuzzing and property tests that specifically target entropy quality, not just functional pass-fail. Block Engineering

For users, the lesson is not to trust any single source of randomness without a way to reinforce it. Dice input looks old school, but it is transparent and audit-friendly. When a vendor offers it, use it. When they do not, consider whether that is a deal-breaker for your threat model.

For vendors, publish clear threat models for your RNG, document entropy sources, and expose health metrics or self-tests users can verify. Also, make migrations boring. The more routine the recovery and rotation flow feels, the fewer users will get stuck on vulnerable seeds during events like this.

Frequently Asked Questions

Does updating my Coldcard now protect coins in a wallet created last year?

No. Updating is important for future operations, but it does not change the entropy of a seed already created. If the original seed was generated on affected firmware without sufficient dice input, migrate to a new seed.

How many dice rolls do I actually need?

At least 50 independent rolls of a six-sided die. That provides about 129 bits of entropy, which meets the 128-bit target and strengthens generation even if the device RNG misbehaves.

Which firmware versions fix the issue?

Per Coinkite’s advisory: Mk2/Mk3 fixed in 4.2.0, Mk4/Mk5 standard in 5.6.0, and Q standard in 1.5.0Q. Install the correct build for your model, verify signatures, then generate a new seed. Coinkite

Is a strong passphrase enough to save an affected wallet?

If a strong passphrase was used from day one, it can raise the security level. Adding a passphrase later does not protect UTXOs already sent to addresses derived from the weak seed. The safer route is to generate a new seed and move funds.

Are multisig wallets safe from this bug?

Multisig changes the attack cost, but any signer whose seed was generated on vulnerable firmware reduces security. Check all signers. If one is weak, rotate that signer’s seed and move to a refreshed quorum.

How urgent is this if my funds are split across many small UTXOs?

Still urgent. Attackers target predictable seeds, not specific UTXO sizes. You can migrate in phases to keep fees manageable, but start the process soon.

What if I used dice but can’t remember how many rolls?

If you did not record the count and the seed was made during the affected window, assume it is unsafe and plan a migration. The cost of moving is lower than the risk of guessing wrong.