A guest essay published by Bitcoin Magazine argues that the Coldcard seed-generation flaw has become a live example of why software security cannot rest on obscurity. The article, written by Fedi content producer Colin Crossman, says users who followed standard practice still lost Bitcoin: they bought a well-regarded hardware signer, generated a seed offline on the device, and trusted it to do the one job a signer must do correctly — produce a number nobody else can guess. According to the piece, Coldcard failed at that step.
How the flaw worked
Crossman writes that a preprocessor guard checked the wrong thing and quietly routed seed generation away from the hardware entropy source to a weaker software pseudorandom number generator, MicroPython’s Yasmarang. On some models, effective entropy fell to around 40 bits.
The flaw, the article says, shipped in March 2021 and remained in publicly readable firmware for more than five years before the reason for the thefts became clear. Attackers first swept 500 addresses. Within days, Galaxy Research’s count had climbed to 4,585 addresses and nearly $90 million. The article says the attack was still ongoing as of its publication date.
Coinkite’s working assumption, described by Crossman as widely shared on X, is that someone used AI to comb through the public firmware and locate the bug. He adds that even if this attacker did not find it that way, the next one likely will.
AI audit missed it, later tests found it in minutes
The essay says an AI-assisted audit had been run weeks before the thefts and found nothing. Crossman says that may have reflected either the model’s capabilities or the way the search was constructed.
After the attack began, though, researchers showed that several frontier models could find the same flaw in minutes from a single prompt. One of the author’s central points follows from that contrast: the code sat open to human review for five years, and no human reviewer caught it.
License changes did not stop the bug
Crossman recounts that Coinkite moved its firmware from a free-software license to source-available terms, specifically MIT with a Commons Clause, after Foundation Devices used the code in a competing product. The source remained readable, but the license no longer allowed someone to build a business on it.
That, he argues, changed little. The bug remained in code that machines could read regardless of what the license allowed. He also notes that the flaw entered the codebase during the rewrite that removed the last of the GPL code.
His conclusion is direct: the licensing change did not increase protection. It only changed the economics of finding the flaw. In an era of increasingly capable AI, everything that gets distributed is readable, or soon will be.
Closed-source protection is described as a human comprehension barrier
The article then broadens the point beyond one hardware wallet. Even a stripped binary, Crossman writes, can be decompiled into pseudo-C. He uses the kind of output familiar to anyone who has opened Ghidra: unnamed variables, flattened control flow, and functions labeled with names such as FUN_00401a20. Most people will not want to read that. In his view, that difficulty has been the entire security premium of closed source.
A compiled program cannot conceal what it does from the machine that runs it. At execution time, the processor must receive the actual instructions, which means the machine code contains a complete account of the program’s behavior. Obfuscation does not remove that information, the essay argues. It only makes extraction harder for humans.
Crossman then compares binary analysis with a much harder class of work: mathematical invention. Reading a binary is an extraction problem, he says, because every fact is already present. Producing a new mathematical object is a different order of difficulty.
The essay points to recent AI math results
To make that case, the article cites a sequence of recent results. At 02:19 UTC on July 20, mathematician Levent Alpöge, working with Anthropic’s Claude Fable 5, posted a counterexample to Keller’s Jacobian conjecture, an open problem dating to 1939 and listed among Stephen Smale’s challenges for the twenty-first century. Crossman says the disproof consisted of three polynomials in three variables, was verified by Lean within hours, and was short enough to be checked in a computer algebra system in about a minute.
He also says an OpenAI model in May toppled the Erdős unit-distance conjecture, and that in late July a 30-year-old graph-theory conjecture fell to four prompts. Between those results came the Jacobian disproof and several other advances on problems that had stood for decades.
Placed next to that pace, the essay says, the task of reading machine code already sitting on the internet looks modest.
A thin binary edge remains, but the author says it is shrinking
The article does acknowledge that current models handle source code and decompiler output better than raw bytes. A fully closed binary still keeps a narrow margin. Crossman describes that margin as a cost speedbump, not a durable defense, and says it is eroding quickly.
Betting security on how long that margin lasts, he writes, means betting against a clock that keeps accelerating. The same class of capability that can spot an entropy bug can also read a proprietary method.
That has implications far beyond open-source debates. Companies that never thought of themselves as exposed to open-source issues may still be relying on trade secrecy embedded in shipped software. Crossman’s formulation is that software trade secrecy was always obscurity dressed up in legal form. Trade-secret law has long treated reverse engineering of a lawfully possessed product as fair play, he writes, so a secret survives only while reverse engineering remains expensive.
Once extraction falls to the cost of a subscription and a prompt, code delivered to customers stops functioning as a secret. The article applies that logic to proprietary algorithms, undocumented formats, and binary-embedded advantages, all of which may become legible on a timeline measured less in years and more in minutes.
Open source is not automatically safe
Crossman does not present openness as a security cure-all. He points to Heartbleed, which remained hidden for two years in the world’s most widely deployed TLS library, as evidence that visibility without funded attention can still miss serious problems. He also cites the xz backdoor to show that the open contribution model is itself an attack surface, one that a patient adversary can exploit over a long period with apparently benign contributions.
His narrower claim is that openness still buys concrete things: reviewers are permitted to inspect the code, builds can be independently reproduced and verified, users have an exit if a vendor disappears or changes direction, and the development process starts from an honest admission that someone hostile will eventually read the shipped code anyway.
Use the same models before release
The piece says defenders have one structural advantage attackers do not: time. A team can run frontier models against its own code before release, in the window between commit and shipment, while an attacker has to wait for a binary that does not yet exist.
Crossman argues for reproducible builds so binaries can be tied back to source and the source can be checked. He also calls for systems that fail closed and for trusted cores small enough that one bug cannot compromise everything.
What the author says Bitcoin custody should learn from Coldcard
For the specific task of holding Bitcoin, the essay lays out three lessons it says the Coldcard incident is teaching in real time. First, control the entropy you cannot afford to have guessed. Second, keep the secure element minimal and behind a published interface. Third, spread keys across independent implementations so no single device and no single vendor mistake defines the full risk.
Crossman says the stakes are harsher in Bitcoin than in many other settings because knowledge of private keys is enough to confer possession. The entropy flaw, in his telling, leaves permanent damage. Patching the generator does nothing for seeds it already produced. If the keyspace is weak, it remains sweepable forever, and disclosing the issue effectively hands over the recipe.
Milk Sad is cited as a precedent
The article says the pattern is not new. It points to the Milk Sad vulnerability in the libbitcoin explorer tool, bx, where private keys were seeded from a 32-bit value. According to the essay, attackers were draining wallets generated by that flaw before it was ever publicly disclosed.
Attackers keep their own timeline, Crossman writes. For money that cannot be clawed back, “findable eventually” is effectively another way of saying “gone eventually.”
The closing argument: Bitcoin itself never relied on obscurity
The essay ends by grounding the argument in Bitcoin’s own design. Bitcoin, Crossman writes, never trusted obscurity. Its protocol is open, its rules are checkable by anyone, and its security rests on mathematics and incentives visible to all rather than on hidden implementation details.
He argues that the hardware and software built around Bitcoin should be held to the same standard because the alternative is no longer realistic. In his framing, the real choice was never open versus closed. It was disciplined versus exposed.
Crossman sums up the broader Coldcard lesson this way: closed-source software is like a seed generated by a broken Coldcard. It may look fine, but it is built on sand. Everyone will be able to read the code eventually; the remaining question is whether developers acknowledge that reality up front, or whether users discover it the way some Coldcard users did, one drained address at a time.
The essay is a guest post by Colin Crossman, a content producer at Fedi. The opinions expressed are his own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.