r/Bitcoin: the case for multi-source, fail-closed entropy after the COLDCARD incident

 
 Important: in iancoleman tool I could not use the option for dice (1-6) because it converts 6 to 0 and it gives different result than coldcard's script.  
 But if you put **Base 10** \[0-9\] option, then you get the same seed. Also need to put Mnemonic Length = 24 words.
+
+comment: p3lfeqf
+parent: t3_1vjn3u5
+author: sporastefy
+created_utc: 1786687513

Organisation

reddit

Evidence role

Community discussion

Published

not established

Source changes

1

Detected differences

1

Unreviewed

0

Copies held

2

Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked 15 Aug 2026, 12:28 UTC.

1. source content difference between 12 Aug 2026, 04:47 UTC and 14 Aug 2026, 08:30 UTC Current source content +28 -0

   The Reddit thread gained a new top-level comment by sporastefy arguing that silent entropy degradation is the actual defect and that reproducible builds are the only way to close the gap between published source and shipped firmware.

   seen 14 Aug 2026, 08:30 UTC · Captured here 25,933 chars
   What changed from the previous capture 28 lines

    
    Important: in iancoleman tool I could not use the option for dice (1-6) because it converts 6 to 0 and it gives different result than coldcard's script.  
    But if you put **Base 10** \[0-9\] option, then you get the same seed. Also need to put Mnemonic Length = 24 words.
   +
   +comment: p3lfeqf
   +parent: t3_1vjn3u5
   +author: sporastefy
   +created_utc: 1786687513
   +edited: false
   +body:
   +Disclosure first: ERA Wallet are running a bounty for discussion of this incident, which is what got me to write it up. They asked for honest opinions including criticism. Most of what follows is about Coldcard and about builds, and you can weigh the rest accordingly.
   +
   +I've spent about thirty years doing Linux systems and distribution work, including co-founding a Debian fork and writing the tooling that merges and republishes its signed package archive. That background makes me read this story differently from most of the coverage.
   +
   +Nobody broke the cryptography here. The cryptography never ran.
   +
   +A build configuration error meant seed generation fell back to a software PRNG instead of the hardware entropy source. Not a weakness in the algorithm, not a flaw in the maths — the good path simply wasn't the path that shipped.
   +
   +Two things follow from that, and I think the second one matters more than the entropy discussion this thread has mostly been having.
   +
   +**Silent degradation is the actual defect.** The PRNG isn't the bug. The bug is a fallback that quietly continued instead of stopping. A weak seed is indistinguishable from a strong one — same 24 words, same checksum, same everything — so there is no runtime check that catches it and no user who can tell. The only detector is somebody draining the addresses, five years later. Anything that cannot reach its entropy source has to refuse to generate a key and say so on screen. In systems work this is old: a service that fails silently is far more dangerous than one that crashes, because the crash gets fixed on Tuesday.
   +
   +**It was a build problem, and open source did not catch it.** You put reproducible builds in your list of what you still want, and I'd argue it belongs higher than that — not one item among several, but the thing the whole incident turns on. Coldcard's source was open. People read it. The divergence was between what the source said and what the build produced.
   +
   +Open source tells you what the code says. It does not tell you what is running on your device.
   +
   +Reproducible builds are the thing that closes that gap, and only that. If an independent party can rebuild the shipped firmware byte-for-byte from published source, a build-configuration divergence stops being invisible. Debian has been grinding at this problem for over a decade and it is largely solved there. A hardware wallet holds bearer assets. It should be held to at least the standard we hold a package manager to, and right now most of them aren't.
   +
   +So the question I'd put to any vendor, including the one paying for this discussion: are your builds reproducible, and can a third party verify that the firmware on my device matches your published source? "We're open source" is not an answer to that question. Coldcard was open source and it still lost the money.
   +
   +For what it's worth, ERA's own write-up does address the silent-degradation half properly — they describe a quality gate that rejects weak input rather than accepting it, and collection that fails cleanly. That's the right instinct and more than most vendors bother with. But their article doesn't mention reproducible builds or firmware verification either, so the second half of the problem is open there too.
   

   Extracted text as captured

   post: 1vjn3u5
   author: CommercialMonth3640
   created_utc: 1786273660
   title: ColdCard users lost ~1,367 BTC (~$89M) because a 2021 firmware bug silently swapped hardware RNG for a software one — the case for multi-source, fail-closed entropy
   body:
   Verification because this sounds unreal: Privacy Guides and The Hacker News both covered it at the start of August 2026 — attackers drained thousands of ColdCard wallets for a total of \~1,367 BTC (\~$89M). Root cause: a firmware bug from 2021. During seed generation some devices silently fell back from the hardware RNG to a weak software RNG. The 24-word seeds looked completely normal — no warnings, nothing. But they could be reconstructed offline, years later.
   
   The scary part is that weak randomness looks identical to good randomness, right up until someone else derives your keys. ColdCard's incident was a trust failure: a single chain of trust ("one certified chip from a trusted vendor") that had a silent fallback path. It's now the clearest proof that one point of trust in entropy is one point of failure.
   
   This is why I now look at entropy architecture differently:
   
   1. Certified chip ≠ failure-proof design. A certified secure element is a vendor claim, not a guarantee. If the firmware around it can silently fall back, the certification is worthless exactly when it matters.
   
   2. Multi-source matters. Two independent chips from two manufacturers (STM32 TRNG + NIST SP 800-90B certified ATECC608C) each harvest separate physical noise. Compromising one does not compromise the seed — because the SHA-256 blend cannot be reversed. One honest source in the mix keeps the output unpredictable.
   
   3. Fail-closed is the property that matters. Some wallets now run on-device statistical randomness tests on every entropy input. A lazy swipe, a camera pointing at a table, an idle device — the input is rejected and the step repeats. The device refuses to continue rather than accept bad entropy. That is exactly the property ColdCard's 2021 fallback violated.
   
   4. User-entropy input (camera, screen drawing, device shake) kills the "factory deck" problem. No manufacturer could have precomputed your room and your motion at that moment.
   
   What I still want before trusting large amounts (honest concerns):
   - Firmware transparency: third-party audits, reproducible builds, published entropy logs. A paper describing the pipeline is not the pipeline.
   - Some wallets only mix user entropy in an "expert flow"; the standard flow still relies on the two hardware chips. Those are solid, but a user decision shouldn't change the security floor.
   - Side-channel and fault attacks still exist — more sources reduce risk, nothing is absolute.
   
   The bar I'll use after this incident for any hardware wallet I recommend: "Can this device fail closed — refuse loudly when entropy is weak — or does it silently continue?" ColdCard silently continued. Everything else is marketing.
   
   
   
   comment: p2mkyzy
   parent: t3_1vjn3u5
   author: Neverjetni
   created_utc: 1786274459
   edited: false
   body:
   Would you advise users who generated their seed with Trezor one to redo it?
   
   comment: p2mldk1
   parent: t1_p2mkyzy
   author: MrBansal
   created_utc: 1786274638

   Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.

2. Earliest copy held
   seen 12 Aug 2026, 04:47 UTC · Captured here 22,591 chars
   Extracted text as captured

   post: 1vjn3u5
   author: CommercialMonth3640
   created_utc: 1786273660
   title: ColdCard users lost ~1,367 BTC (~$89M) because a 2021 firmware bug silently swapped hardware RNG for a software one — the case for multi-source, fail-closed entropy
   body:
   Verification because this sounds unreal: Privacy Guides and The Hacker News both covered it at the start of August 2026 — attackers drained thousands of ColdCard wallets for a total of \~1,367 BTC (\~$89M). Root cause: a firmware bug from 2021. During seed generation some devices silently fell back from the hardware RNG to a weak software RNG. The 24-word seeds looked completely normal — no warnings, nothing. But they could be reconstructed offline, years later.
   
   The scary part is that weak randomness looks identical to good randomness, right up until someone else derives your keys. ColdCard's incident was a trust failure: a single chain of trust ("one certified chip from a trusted vendor") that had a silent fallback path. It's now the clearest proof that one point of trust in entropy is one point of failure.
   
   This is why I now look at entropy architecture differently:
   
   1. Certified chip ≠ failure-proof design. A certified secure element is a vendor claim, not a guarantee. If the firmware around it can silently fall back, the certification is worthless exactly when it matters.
   
   2. Multi-source matters. Two independent chips from two manufacturers (STM32 TRNG + NIST SP 800-90B certified ATECC608C) each harvest separate physical noise. Compromising one does not compromise the seed — because the SHA-256 blend cannot be reversed. One honest source in the mix keeps the output unpredictable.
   
   3. Fail-closed is the property that matters. Some wallets now run on-device statistical randomness tests on every entropy input. A lazy swipe, a camera pointing at a table, an idle device — the input is rejected and the step repeats. The device refuses to continue rather than accept bad entropy. That is exactly the property ColdCard's 2021 fallback violated.
   
   4. User-entropy input (camera, screen drawing, device shake) kills the "factory deck" problem. No manufacturer could have precomputed your room and your motion at that moment.
   
   What I still want before trusting large amounts (honest concerns):
   - Firmware transparency: third-party audits, reproducible builds, published entropy logs. A paper describing the pipeline is not the pipeline.
   - Some wallets only mix user entropy in an "expert flow"; the standard flow still relies on the two hardware chips. Those are solid, but a user decision shouldn't change the security floor.
   - Side-channel and fault attacks still exist — more sources reduce risk, nothing is absolute.
   
   The bar I'll use after this incident for any hardware wallet I recommend: "Can this device fail closed — refuse loudly when entropy is weak — or does it silently continue?" ColdCard silently continued. Everything else is marketing.
   
   
   
   comment: p2mkyzy
   parent: t3_1vjn3u5
   author: Neverjetni
   created_utc: 1786274459
   edited: false
   body:
   Would you advise users who generated their seed with Trezor one to redo it?
   
   comment: p2mldk1
   parent: t1_p2mkyzy
   author: MrBansal
   created_utc: 1786274638

   Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.