BitDevs 30_

Chainalysis's first-look thread on the $38M+ initial drain. The attacker prioritized the largest wallets first — three of the top ten held 10+ BTC each — pushing cumulative theft to ~$30M in the first 10 minutes and 500 wallets in 25 minutes. Their bottom-line advice: applying the hotfix is NOT enough if your seed was generated on vulnerable firmware — you must generate an entirely new seed on patched hardware, ideally with a BIP-39 passphrase. Good discussion hook: is fingerprint-based attribution useful evidence, or just marketing for chain-surveillance firms?

The definitive forensic thread. Galaxy expanded on Block's engineering fingerprint (30 sat/vB fixed fee, single-output batches, no change, P2WPKH inputs) and traced two distinct sweep waves: 1,082.65 BTC from 1,195 addresses in a 41-minute window on July 30, then a slower 76.16 BTC from 1,478 addresses over 3h42m on July 31. Every drained coin was created after block 674,951 (March 17, 2021) — the block the vulnerable firmware shipped. The loss profile skews to small self-custody addresses in count but large ones in value, and the funds sit unspent — no laundering path for a sum this visible. Migrate any Coldcard-generated single-sig seed immediately.

The best piece of on-chain research from the whole event. Anagram built a detector for "dormant coin from a Coldcard-shaped single-sig address to one fresh unlabeled address" and ran it across the disclosure week vs three normal weeks. Baseline: ~4,000 sweeps/week. Disclosure week: 46,000. That's ~42,000 excess transactions moving ~36,000 BTC — most of it owners escaping, not thieves stealing. The heist and the escape look structurally identical on-chain; only extreme fan-in (single addresses collecting 20+ sweeps) is a reliable tell for theft. They also flag block 960,359 as a suspected unattributed Wave 1.5.

The disclosure that broke the story. Block's Engineering and Security teams identified the predictable RNG fallback and 32-bit reseed in Coldcard firmware and told users how to check their exposure. Notable that Block — Bitkey's parent — was the entity that actually did the reverse-engineering, published the technical details responsibly, and told users to migrate. Discussion hook: this is the model of how a competing manufacturer should behave during a disclosure.

Beac's technical thread with a working PoC on GitHub. Root cause in one line: rng_get() was linked to MicroPython's software PRNG instead of the STM32 hardware TRNG, so Mk3 seeds had ~2^40 effective states (not 2^256), and a follow-up analysis collapsed the pad to a single 32-bit word — meaning every Mk2/Mk3 shares a universal 2^32 pad space. One offline sweep of all funded addresses recovers every weak wallet at once. This is the seminar's key math: 2^40 (or 2^32 in the worst case) vs 2^256.

Core Lightning dev Dustin Dettmer walked the actual Coldcard firmware commit history and reconstructed what happened. The commit that introduced the bug touched ~2,500 lines of the most security-critical code in the codebase — the RNG plumbing. Read this one before the seminar; it's the technical spine of the entire story.

The single most damning quote from Dettmer's analysis, boiled down: the developer hit a "duplicate symbol" compiler error while wiring libngu into Coldcard, couldn't resolve it, and set MICROPY_HW_ENABLE_RNG to 0 to make the error go away. That flag disabled the STM32 hardware TRNG and silently fell back to MicroPython's Yasmarang software PRNG. The commit message was literally the single word "runs." Four years and ~$75M later, here we are. Discussion hook: what would code review, unit tests for the RNG, or a two-engineer approval requirement have caught?

A cleaner prose version of Dettmer's analysis if the substack is too dense — three layers of the firmware (Python wallet code, MicroPython C, STM32 hardware) collided, the fix silenced the compiler instead of resolving the conflict, and the fallback PRNG made it into production. Ends on the right lesson: don't ship security-critical code you don't understand.

A four-image explainer thread from the Bitcoin Dev Project. Good for members who want the concept without the C code — walks through what entropy is, why 2^40 is broken and 2^256 is safe, and how the attacker turned a weak RNG into a working sweep. Useful as the intro visuals for the seminar's technical block.

Filini looked at the libngu-introduction commit and noticed something the other analyses missed: the swap from hardware TRNG to weak PRNG wasn't applied uniformly across the codebase — only certain RNG call sites were changed. That's an odd pattern for a "just make it compile" fix; it either points to selective testing (some paths were tested, others weren't) or something more deliberate. Great discussion hook: intent vs incompetence, and how you'd tell them apart from the commit history alone.

Kevin Loaec's follow-up analysis on the real entropy level — separating what Coinkite's "~40 bits" claim counts (UID + SysTick + RTC) from what the pad-collapse argument shows (a single 32-bit output space in the worst case). Also digs into collision risk between users and how each of Coldcard's supposed "entropy sources" was actually triggered in code. The most rigorous technical follow-up we've seen so far.

Someone tried to prompt-inject the sweeping bots by embedding LLM instructions in OP_RETURN or address metadata. It didn't work but it's genuinely funny — the state of 2026 crypto crime includes trying to jailbreak the attacker's own automation. Juliano's follow-up correctly pivots to the serious point: use the attention to warn Coldcard users to move funds.

The community's response to years of Coldcard marketing that trashed competing hardware wallets. This one lands because it's true — a company that spent years positioning itself as the security-maxi option shipped a broken RNG for four years. Discussion hook: what does this do to hardware wallet marketing overall? Does anyone deserve trust after this?

Four years ago a user reported their Coldcard was drained after using the on-device RNG feature without dice rolls. Coldcard blocked him instead of investigating. If this reporting is accurate, there was signal in 2022 that got dismissed — turning a shipping bug into a preventable four-year-long exposure window. Hard discussion hook: what does responsible disclosure look like when the affected vendor is hostile to the reporter?

A walk through the actual Coldcard/firmware GitHub repo. Most commits go straight to master. PRs that do get opened are merged without a single comment. Many commits have no explanation at all. This is the process context in which the "runs" commit shipped — and it's the answer to "how could this have happened?" The answer is: exactly the way you'd expect, given this workflow.

The rushed firmware hotfix introduced its own critical failure — a transient STM32 TRNG error can now permanently fault the RNG, and because it's used before the PIN screen, affected devices are effectively bricked. So the fix for the RNG-that-wasn't-random is a code path that can brick your Coldcard. This is the worst possible follow-up to a security disclosure.