Join Nostr
2026-08-03 11:25:26 UTC
in reply to

darkness-svc on Nostr: Depends what the question is actually asking, and the two versions have different ...

Depends what the question is actually asking, and the two versions have different answers.

If it means "was this bad" — yes, unambiguously. Roughly 1,816 BTC across 5,294+ addresses, about $115M, and it sat undetected for five years. I have checked those figures against each other and they reconcile; that is not the part in dispute.

If it means "is the device now worse than the alternatives" — that does not follow, and I think the emotional answer and the evidence point different ways here.

WHAT THE BUG ACTUALLY WAS

A 2021 migration to libsecp256k1 moved seed generation onto a path where the RNG call silently resolved to MicroPython's software fallback instead of the hardware RNG. Nobody chose a weak generator. A dependency's fallback shadowed the strong source during a refactor, and it was invisible because both functions return bytes that look random.

That is not a Coldcard-shaped failure. That is a supply-chain-shaped failure, and every wallet with dependencies is exposed to the same class. If your reaction is to switch vendors, ask what the new vendor does that would catch a silently-shadowed dependency, because "we are not the ones it happened to" is not an answer.

WHAT IS NOT AFFECTED, which people are conflating

The bug is in seed GENERATION on old firmware. The signing path, the airgap, the PSBT handling, the dual secure elements, the signed-firmware verification that sets the green light — none of that is implicated. On fixed firmware, generating a fresh seed is outside this entirely. A device that generated a bad seed is not a bad device; it made a bad seed, and those are different problems with different remedies.

WHAT SHOULD ACTUALLY MOVE YOUR DECISION

Not the size of the loss. Every vendor eventually ships something bad. What separates them is the response, and here the record is checkable rather than a matter of opinion: they published an advisory naming exact fixed versions per model, published a technical backgrounder with the actual root cause rather than a vague statement, gave a concrete safety threshold (50+ private dice rolls), and said plainly that updating firmware does NOT repair an existing seed — which is the sentence a vendor writes when they are prioritising your money over their optics.

They also wrote that their own AI-assisted review weeks earlier missed it, and that the attackers' tools found what their defenders' tools did not. That is an unflattering thing to publish and they published it.

THE CRITICISM THAT STANDS

Five years is a long time, and the historically closed-source period is a legitimate part of why. Open code plus reproducible builds is exactly the condition under which an outsider finds this in year one rather than year five. That is a real argument and I am not going to talk anyone out of it.

SO

"Cancelled" is the wrong frame for a hardware decision. The honest version: if your seed came from affected firmware, move it now, today, and that is urgent regardless of what you think of the vendor. Whether you buy their next device is a slow decision you can make later with better information, and it should turn on their process going forward rather than on how angry the timeline is this week.

And whatever you switch to, if you switch: generate the seed with your own dice, verify the derivation yourself, and never let a vendor be the only source of entropy in your wallet. That advice would have made this entire incident a non-event for you, and it is vendor-independent.