Jonathan Goodman did what a careful person is supposed to do with a fortune in bitcoin. He generated his seed offline, on a Coldcard, and never typed it into anything connected to the internet. He split his backups across multiple safes and a safety deposit box. When the Coldcard entropy bug drained his wallet along with thousands of others on 30 July, he described his own setup plainly: “I never shared my seed phrase with anybody. My devices never touched the internet,” and “everything was kept in multiple safes and safety deposit boxes.” Four separate defences, by most people’s count, and, by his own account, 18.25 BTC, close to $1.6 million Canadian, gone anyway. Engineers have a precise name for what happened to setups like his: common cause failure, not bad luck.

The bug itself, a March 2021 firmware build that generated wallet seeds with far less randomness than it should have, has already been covered in detail, including which storage setups survived and which didn’t, in Silicon Canals’ earlier reporting on the exploit. What that piece didn’t get into, and what actually generalises past bitcoin, is the specific shape of Goodman’s mistake, and it is a mistake plenty of careful people make in domains that have nothing to do with crypto.

Careful people, and a very particular kind of careful

The wallets drained in the sweep were overwhelmingly single-signature, and a large share belonged to long-term holders whose seeds had been generated years earlier on the vulnerable firmware and then left alone. One victim who spoke to The Defiant had been accumulating since 2015 and stamped his seed into a steel plate for permanence. Another had bought a device specifically to hold savings meant for his children. These were not people who cut corners. They were, by any ordinary measure, the most security-conscious cohort on the network, and the security they built had a specific, repeatable shape: several independent-looking copies of the same underlying secret, protected against theft, fire and prying eyes, and never checked for whether that secret itself had been generated soundly.

Goodman’s account is the cleanest version of it. Multiple safes and a safety deposit box defend against someone breaking into his house or his bank. A device that never touched the internet defends against remote hackers. Both precautions did exactly what they were built to do, and neither was wasted: the threats they defended against are real, and the defences against them worked. What they had in common is the problem. All of them defend against the same category of threat, an attacker trying to physically or remotely reach his keys, and none of them had anything to say about whether the keys were weak the moment the device created them. His redundancy was real. It was also stacked entirely on one axis.

The engineering term for exactly this

Reliability engineers have studied this pattern for decades under the heading of common cause failure, sometimes called common mode failure, the two terms used interchangeably. The underlying logic is straightforward once it’s named: redundancy only improves a system’s reliability when the backup copies can fail independently of each other. When two or more components share a cause of failure, whether that’s a shared manufacturer, a shared maintenance routine, or, in Goodman’s case, a shared seed, the system’s overall failure probability can never drop below the probability of that shared cause failing. Extra copies stop adding safety the moment they stop being independent, and common cause failures defeat redundancy precisely because the dependency hides inside something that looks, from the outside, like genuine backup.

The textbook illustration is a facility with two backup generators, installed specifically so one can fail without consequence. Both are serviced by the same technician, who follows one incorrect maintenance procedure across both machines. The first generator fails during a real outage. So does the second, for the identical reason, at almost the identical moment, and the redundancy the facility paid for turns out to have been an illusion the entire time it wasn’t being tested. Coldcard’s safes were the second generator. Same manufacturer, same firmware, same seed, one code path underneath every backup that looked, to Goodman, like three.

How often the illusion actually shows up

Two figures are worth holding onto here, because both cut against overreading the lesson. In nuclear plants, common cause failures have been found to account for between 20 and 80 percent of the total unavailability of safety systems, depending on the system studied, which is a wide enough range to tell you the problem is real and unevenly distributed rather than a fringe case. NASA’s own reliability research puts the figure closer to ten percent of all failures, meaning roughly ninety percent of failures behave the way redundancy assumes they will: independently. That second number is the honest counterweight to the first. Most of the time, backups actually are backups, which is exactly why almost nobody thinks to check the axis before something like Coldcard forces the question. NASA’s own researchers go further, arguing that common cause failures trace back to engineering and design errors and ought to be found and removed rather than simply priced into a probability estimate; the fix is inspection and removal first, with better math only for whatever’s left over.

What actually held, and why

The Coldcard sweep also showed the inverse of the principle, briefly worth naming since it proves the point rather than just illustrating the failure. Multisignature setups, which require signing keys from more than one independent device before funds can move, largely held, because the vulnerable seed was only one input among several rather than the entire dependency. A genuinely strong, randomly generated BIP-39 passphrase held too, because it created a second, effectively separate wallet that couldn’t be reconstructed from the compromised seed words alone. Both worked for the same reason the safes didn’t: each introduced a failure mode that was actually distinct from the others, not just a second copy of the same one.

Where this shows up outside a hardware wallet

This isn’t really about bitcoin so much as a description of how redundancy quietly becomes decorative once every copy is exposed to the same failure — a pattern that turns up constantly in ordinary technical life, mostly unquestioned:

  • Three copies of a backup, all stored in the same house, or all synced to the same cloud account.
  • A long, unique password on every account, all of them held inside one password manager.
  • Two-factor authentication turned on everywhere, with every single code arriving on one phone number that can be SIM-swapped.
  • Two bank accounts, at two different institutions, that both clear payments through the same third-party processor.
  • Two hard drives bought at the same time, from the same production batch, running the same firmware.

Every one of these looks like redundancy on a spreadsheet. The question that actually separates real redundancy from stacked redundancy isn’t how many copies exist. It’s whether those copies would fail for the same reason.