Bitcoin Magazine

Hunting Down the Coldcard Hacker. Wave 1 Thief May Be Known to FBI

Law enforcement may already know who emptied more than a thousand Bitcoin from Coldcard wallets in the first and largest wave of the July 2026 drains. Block’s investigation believes they traced the attacker’s on-chain sweeps to a paid account at a major blockchain data provider whose internal logs matched the theft pattern with “extraordinary specificity.” 

PSA: The attack is ongoing, targeting weak private keys generated on devices as old as the MK2 with firmware 4.0.1 onwards. If you may have one, double-check and move funds asap. See Coinkite advisory and status page. 

The coins from that wave—1,082.65 BTC—still sit untouched in the attacker’s address, leaving hope that a clawback may be possible to the victims and rightful owners of that first wave of stolen bitcoin. The question now is, who is the hacker and whether the same lead points to a sophisticated outsider, or whether the five-year-old entropy bug that made the theft possible was something closer to the insider “retirement attack” Coinkite itself once warned about.

What We Know

On July 30, 2026, an attacker began systematically draining Bitcoin from Coldcard hardware wallets that had generated seeds under vulnerable firmware, a bug that was undiscovered for years. The first and largest wave alone moved 1,082.65 BTC. Subsequent waves followed, with estimates over 2k BTC. Alex Thorn at Galaxy Research has tracked the activity through a combination of on-chain pattern analysis and voluntary victim reports. As of early August, confirmed and estimated losses across multiple waves exceeded 1,800 BTC from more than 5,000 addresses, though exact final totals continue to be refined as new reports arrive. In dollar terms, roughly $118 million has been confirmed stolen.

Thorn has publicly discussed the possibility that law enforcement already holds a concrete lead on the operator behind the largest tranche. In a Bitcoin Policy Institute segment hosted on the Bitcoin Magazine YouTube channel, Thorn stated: “Wave one’s identity, attacker identity, may be known to law enforcement.” He added that Wave 1 remains the biggest single chunk identified so far, with the coins still sitting in the attacker’s address, and noted that Wave 2’s pattern looks similar enough that it could involve the same actor. Wave 2 adds another 76 or so bitcoin to the total. 

The primary source for the claim that the hacker’s identity might be known is Clay Garrett, engineering lead at Block working on Bitkey. On July 31, 2026, Garrett posted the findings from Block’s investigation:

“During our investigation of the Coldcard drain yesterday, we identified an unusual pattern in the sweeps. That pattern led us to a hypothesis that has since been confirmed: the operator used a paid account at a well-known blockchain-services provider to query the source addresses and perform other related activity during the sweeps.”

“We contacted the provider directly. Their internal logs matched the suspected workflow with extraordinary specificity, including the number, timing and sequence of requests. The provider was supplying its standard services in response to requests that did not reveal their broader purpose. We have seen no evidence that the provider knowingly participated in or facilitated the suspected theft.” Garrett said, and added that; “We are sharing the relevant information with the appropriate authorities. We will provide further updates when doing so will not interfere with the investigation.”

Thorn and others have noted that later, smaller waves show different operational patterns—some rapid, opportunistic drains followed by quick laundering—suggesting additional actors may have reverse-engineered the same weak seed space after the initial public disclosure. Self-reported confirmed drains appear to have slowed sharply after August 6, though many potentially vulnerable seeds generated on the affected firmware between 2021 and the July 2026 patch remain at risk until users migrate.

A Retirement Attack?

The nature of the failure has led to conspiracy theories about insider attacks that Coinkite itself once discussed publicly. In October 2021, the official COLDCARD account defined a “retirement attack” as the scenario “when the project makers could have a ‘bug’ in the entropy generation for later retrieval.” The post is still available here. The 2026 vulnerability produced exactly that outcome: seeds generated with far less entropy than intended, leaving them searchable years later. Some in the Bitcoin space now believe that the hack may have been an inside job at Coinkite, though others disagree and the evidence in the public record remains too scarce to know anything definitive. Further evidence will likely not come out for years, until litigation exposes it.

It’s when the project makers could have a “bug” in the entropy generation for later retrieval.

— COLDCARD (@COLDCARDwallet) October 10, 2021

The critical change entered the codebase on March 1, 2021, in a commit titled “First pass w/ libNgU” (b18723dd). That commit replaced remaining Trezor-derived cryptography and BIP-39 code with a new library, libngu, and rewired seed generation. The intended result was that the call for randomness resolved to the STM32 hardware’s true random number generator. However, the bug redirected the call to MicroPython’s software Yasmarang PRNG instead, resulting in an effective entropy collapse to roughly 40 bits on older models and around 72 bits on newer ones. That meant the Bitocin private keys generated were effectively guessable by modern computing hardware. This swap of cryptographic libraries was pushed to the codebase by Doc-Hex, also known as Peter Gray, the Chief Technical Officer of Coinkite. 

The move was arguably driven by licensing pressure, according to Foundation Devices CEO and founder Zach Herbert, though Coinkite has denied this as a primary motivation for the code change, saying, “COLDCARD had to make this change to move to libsecp256k1; the license change is irrelevant to this. libsecp256k1 is the standard library used by Bitcoin Core.”

Coldcard had been using Trezor-derived code under the GPLv3 open source license. After Foundation Devices forked related material, Coinkite sought to move remaining components to a more restrictive MIT + Commons Clause arrangement that limited commercial reuse. The rewrite was large and carried complex engineering goals; it was this integration that arguably left the silent failure in the entropy path.

Skepticism about the migration away from the Trezor crypto library emerged as early as April 7, 2021, by a member of the Coinkite Telegram group, who wrote: “do we really want to replace the many-years-old TrezorCrypto code that has been heavily scrutinized by white hatters like Johoe and penetration tested by wallet.fail”, adding “switch may be a talented pseudonymous coder, but their commit history sucks.” The criticism, however, was insufficient and quickly waved away by NVK, who criticized the Trezor library as a “shitcoin shitshow.” Ironically, sharing that codebase with the broader crypto market, under an open license meant that Trezor’s crypto library had much deeper code review than Libngu would ever get, even years later. 

Switch and Peter Gray aka Doc-Hex

The swap of cryptographic libraries that introduced the bug was pushed to the codebase by Doc-Hex, the Chief Technical Officer of Coinkite, also known as Peter D. Gray. He replaced the GPLv3 Trezor cryptography library with Libngu, a little-known codebase created by so-called “Switch”, a nym that, up until the creation of Libngu, had no obvious previous history. The Switch account appeared on X on August 3, 2019 with a mention of DEFCON, the international hacker’s conference, an event normally attended by cybersecurity engineers of all kinds. 

On October 16, 2020, Switch thanked Doc-Hex on X for merging his code; “Thanks for merge @DocHex … I’m making yet another bitcoin library. Could be useful on @COLDCARDwallet someday.” A few days later, Switch tweeted out a link to Libngu, proud to have built a “useful thing.”  

However, here is where it gets weird. According to research by Bitcoin core contributor James O’Beirne, Switch and Peter D. Gray have signed code commits with the same GPG keys. O’Beirne demonstrated through GPG commit signatures that dozens of commits authored as switck were signed with the personal key of Peter D. Gray, Coinkite co-founder and CTO, who also operates as DocHex. Zach Herbert also claimed that phone numbers ending in the same two digits were tied to both the DocHex and switck X accounts (post). Additional researchers pointed to matching DNS registration patterns.

Neither Gray nor Coinkite has publicly addressed the GPG-signature findings as of this writing, and they did not respond when asked to comment on the topic. The Switch account is still active to this day, having merged code changes to Libngu as recently as August 17th, 2026.

Many in the Bitcoin industry are taking this as some sort of tangential evidence of wrongdoing. Why go out of your way to create a nym just for a particular cryptography library? This has been taken as some kind of evidence of malintent; however, a deeper analysis begs to differ. Had Gray really intended to rug Coldcard users with this RNG bug, would he really have been signing commits with his personal GPG key? Could someone be so cunning that they would hide a bug for years, waiting for its adoption to spread; yet at the same time forget to create a dedicated GPG signature for the throwaway nym? I don’t think that tracks. 

It is more likely that this was a random identity created at DEFCON by Gray, probably in a random bout of paranoia. An identity which he continued to use for certain projects over the years. Pseudonymous identities are not unusual in Bitcoin developer circles after all. Satoshi himself remains the most famous example. And so on its own, this connection between Gray and Switch arguably does not amount to much in the hunt for the Coldcard hacker.

MicroPython Contributors

A handful of other open source developers have also been recently identified as having touched or influenced code that played a role in the Coldcard RNG bug. 

Data Analyst LaurentMT has examined the MicroPython side of the RNG path. MicroPython is a lean and open-source implementation of Python 3, designed to run on microcontrollers and resource-constrained computers. The Coldcard firmware ultimately called MicroPython’s Yasmarang pseudo-random number generator (PRNG) fallback as a result of the bug, leading to low-entropy generation. 

The code changes to the PRNG logic in MicroPython began on August 20, 2020, with issue (#6347) opened on GitHub by a user named ‘mirko’. He complained that his ESP32 hardware was always returning the same result when calling the ‘random.choice()’ function in the code in a certain way. Mirko expected random results instead. The GitHub issue logs a discussion over the following months about the proper way to handle the related logic and expected behavior, which Mirko revealed to have a counterintuitive design. 

Laurent points out that “robert-hh initialized a [Pull Request] implementing the PRNG seeding change” on August 22, 2020. Dpgeorge, a maintainer of MicroPython, later on October 29, 2020, merged a slightly modified version of that pull request to the master repository, implementing “the (UID+SysTick+RTC) to address some limitations in robert-hh’s solution.”

The changes to this critical RNG-related code were thus on the master repository of MicroPython when Coldcard forked it to be used by Libngu, yet before MicroPython had made an official new version release of the library. Apparently, it is considered risky to build on top of the master version of a software repository, which is likely to be evolving with code changes, rather than build on top of an official, stable release version. The new release of MicroPython did not come until February 3, 2021, with version v1.14. To top it off, the RNG logic change was only briefly mentioned in the release announcement, saying “the urandom module will randomize its seed on import on stm32, esp8266, esp32 and rp2 ports.”  

In an interview with Bitcoin Magazine, Laurent concluded in no ambiguous terms that “without this modification the bug in Coldcard code would have been immediately detected.” Commenting on the series of events that led to the bug, he also said that “there are a lot of ‘coincidences’ in this timeline,” adding that “while they don’t prove anything, I don’t see how an official investigation may completely ignore them.”

It is important to note that there is no evidence any of the developers mentioned above were intentionally trying to introduce the Coldcard RNG bug with these changes, and ultimately, it is Coinkite, the hardware wallet company, that is responsible for their implementation of the critical code. MicroPython is a large, widely used open-source project. Nevertheless, there are likely many lessons to be learned from what we might as well call — for the time being anyway — a tragic comedy of errors. 

Why an Inside Job Appears Unlikely

Several factors cut against a deliberate, long-planned insider retirement attack. The ‘switck’ identity was poorly compartmentalized; the shared GPG key and other overlaps made attribution to Doc-Hex aka Peter Gray, relatively straightforward once researchers looked. The account had been largely abandoned for years. The MicroPython contributors operate in the open on a high-visibility project.

Hodlonaut’s Citadel21 investigation and other technical reviews find no clear evidence that the entropy failure was intentional. Engineer Alekos Filini’s technical report on the bug explicitly tracks the technical facts, stating that “My goal is to purely present facts and NOT make any conclusions.” Wizardsardine detailed on their Technical autopsy multiple failed safeguards and describes the failure as sitting “across a submodule boundary, which is precisely where reviewers stop looking.” 

Steven Geller’s technical deep dive on the topic did not make any strong claims either way on the matter. DK27ss proof-of-concept reconstruction of the bug describes the issue as “a chain of four flaws, each harmless in appearance.” 

If the drains had been a classic insider retirement attack, or a long con as some might call it, the conversation today would be quite different. The last time we saw a major long con hack in the Bitcoin industry was probably QuadrigaCX, a centralized Canadian exchange whose founder, Gerald Cotten, was reported “dead in India” in 2018 amid mysterious circumstances, not long after the missing funds were discovered. The founders are accused by the Ontario Securities Commission of having misappropriated the exchange users’ deposits totaling almost 170 million CAD, over many years, before disappearing. 

Instead, Coinkite’s leadership remains publicly active, responding to the incident, shipping patched firmware, assisting user migrations, and engaging on the technical details. Coinkite’s founders and operators are fairly well known and are still operating the company as of the time of writing; they have not disappeared at the same time as the funds went missing.

Meanwhile, the wave 1 funds, totaling over 1000 BTC, are still collected in three addresses, watched by hundreds of engineers and likely law enforcement such as the FBI. Were Coinkite trying to do a 5D chess-style retirement attack, they would have been far more careful in their theft of the coins. They would not have pooled them all to a handful of addresses that are easy to track, and its founders would probably be ‘mysteriously dead in India.’

While there are no conclusions and investigations will likely be ongoing for years, so far, evidence points to a cultural failure in the Bitcoin maximalist and self-custody community, a failure to broadly educate the users and influencers about good or bad etiquette in open-source culture, and frankly, arrogance on the part of Coinkite OG’s who, in hindsight, were overconfident about their own capabilities. 

This post Hunting Down the Coldcard Hacker. Wave 1 Thief May Be Known to FBI first appeared on Bitcoin Magazine and is written by Juan Galt.

Bitcoin Magazine

Bitcoin’s BIP110 Moment: Three Possible Scenarios

Author’s note: In my view BIP110 is both useless and harmful, and I do expect it to fail (see scenario 1). Despite this I tried to write this article as factually as I could, entertaining different possible scenarios, as I do hope it may provide some clarity on this soft fork attempt.

The OP_RETURN debate has escalated to the point where Bitcoin Knots implemented BIP110: a consensus protocol change that temporarily limits the size of OP_RETURNs and intends to reduce other types of data on Bitcoin’s blockchain as well.

However BIP110 does not have consensus: not everyone agrees there’s a problem that requires solving in the first place, nor that BIP110 solves it in any meaningful manner, while it restricts Bitcoin in potentially harmful ways. Most obviously, Bitcoin Core — still by far the most-used Bitcoin implementation — has not adopted BIP110, while only some 1-2% of hash power has been signaling support for it in recent weeks.

Nevertheless, BIP110-nodes like Bitcoin Knots will soon — starting from block 961,632, to be mined on or around August 8 — reject blocks that don’t signal support for the upgrade.

Here are the three main scenarios for how that could play out.

Scenario 1: (almost) no miners signal

If current miner signaling is any indication, this is the scenario to expect.

From the perspective of anyone running Bitcoin Core or other non-BIP110 enforcing nodes and wallets (the vast majority of the Bitcoin ecosystem) blocks will be mined as usual, and transactions will be processed like normal too. Anyone who’s not actively tracking these events on social media or elsewhere may not even be aware that anything unusual is going on, and in a practical sense for them there really won’t be; BIP110 does not affect them.

The same is not true for anyone running Bitcoin Knots or other BIP110-enforcing nodes, however. Since their software will reject non-signaling blocks, they basically wouldn’t see any new blocks at all (or perhaps a few per week), and incoming and outgoing transactions won’t confirm (or incredibly slow). In practical terms, these nodes would stall and become unusable.

If this happens, BIP110 proponents will have to decide between waiting to see if things improve for them (see scenario 3), giving up (switching back to non-BIP110 software), or deploying a next protocol change, like hard forking to a different proof-of-work mining algorithm.

Such a hard fork would possibly allow for mining with GPUs again, therefore letting more people mine new blocks to generate a blockchain with the BIP110 rules enforced. However this would also mean that BIP110/hard fork nodes permanently split off from the rest of the Bitcoin ecosystem to essentially create a new cryptocurrency. (More on this below)

Scenario 2: (almost) all miners signal

This is the scenario several prominent BIP110 proponents predict.

In this scenario, when the mandatory signaling window starts, all miners will suddenly signal for BIP110. Or at least, a majority of miners will signal AND reject any non-signaling blocks, so that all blocks that end up in the blockchain include a BIP110 signal.

If this happens, all Bitcoin nodes (Knots and Core alike) remain compatible, and the signals in the blocks indicate that miners plan to start enforcing the BIP110 rules another two weeks later. BIP110-violating transactions should by early September no longer end up in blocks.

In essence, this is the success scenario for BIP110; although only a small faction of developers, miners and users pushed for it, the upgrade goes into effect across the entire network.

…However even in this scenario there is an important caveat.

Blockchain signaling is a useful coordination mechanism for soft fork deployment, but it technically does not guarantee that the new rules will be enforced. Miners can signal support for the upgrade without actually using BIP110 software, which they for example could elect to do simply to ensure their blocks aren’t rejected by Bitcoin Knots nodes during the mandatory signaling window.

Bitcoin’s protocol rules are ultimately enforced by economic nodes however, and nothing currently indicates that most of these will enforce the BIP110 rules even if all blocks include a signal. So if BIP110-violating transactions are later accepted by most miners regardless, these economic nodes would accept blocks that include them, while BIP110 nodes would not. The blockchain would split between nodes that do and do not enforce BIP110 after all.

Scenario 3: a sizable minority of miners signal

This is the scenario that would immediately split the chain.

Currently some two percent of miners signal support for BIP110, which is probably too little to be meaningful (see scenario 1). But let’s imagine this quickly increases tenfold or so. We also have to imagine that this sizable minority itself rejects any non-signaling blocks— else it would still be indistinguishable from scenario 1 where BIP110 nodes stall (since they require ALL blocks to include a signal).

If the sizable minority is both signaling and rejecting non-signaling blocks, they’d start to build their own minority blockchain with only signaling blocks in it. Blocks on this minority chain would confirm significantly slower than usual — maybe just one or two per hour — but BIP110 nodes remain reasonably usable. And after a few months the mining difficulty would adjust, so blocks are found (closer to) six times per hour again. Another couple of weeks later the BIP110 rules would go into effect.

Meanwhile, Bitcoin Core and other non-BIP110 enforcing nodes would still operate fairly normally as well. Their blocks will confirm a little bit slower for a while — maybe about four or five per hour — but after a couple weeks mining difficulty adjusts here too, to also bring this back to six per hour on average. The BIP110 rules would never go into effect on this blockchain.

As a result, a BIP110 blockchain and a blockchain with the original rules would then exist side by side as two different cryptocurrencies, indefinitely.

There is one notable caveat to this scenario as well, however. If the BIP110 chain were to overtake the original chain in length later on (due to miners moving to the BIP110 chain), all nodes — Core and Knots alike — would accept the BIP110 chain as the only chain. The original chain would in this case be discarded, or wiped out.

This one-sided wipe out risk is in fact why BIP110 proponents expect all miners to signal preemptively, preventing a split. Miners won’t want to mine on a blockchain that can later be discarded, they argue, as that would also mean losing all block rewards they earned on it.

In actuality, users and miners that want to prevent that the original chain can get wiped out could do so however: they can manually invalidate any block on the minority BIP110 chain while it still is the minority chain. This way their nodes would reject switching to it even if it becomes longer at any point in the future, making the split permanent also.

So what exactly happens if the chain permanently splits?

If and when the Bitcoin blockchain permanently splits, it essentially marks the creation of a new cryptocurrency, or forkcoin. Everyone who owns BTC at the time of the split automatically receives the equivalent amount of coins on the new blockchain, not unlike what happened with Bitcoin and Bitcoin Cash in 2017.

However in reality these things aren’t necessarily as straightforward, and if BIP110 does cause a chain split under any of the scenarios above there will likely be some complications.

For one, there’ll almost certainly be disagreement over which side of the chain represents “Bitcoin” (“BTC”), and which side is the new forkcoin. It seems likely however that the blockchain with the original rules will by most people be considered “Bitcoin”, whereas the blockchain with the BIP110 rules will be called something else; we’ll call it “BIP110 coin” for now.

Accessing the BIP110 coins then, will require BIP110-specific software like, indeed, Bitcoin Knots. The new coins won’t show up on Bitcoin Core nodes or most wallets.

However, BIP110 does not currently include replay protection. This means that transactions on one chain can be copied (“replayed”) on the other chain. Instead of just sending BTC, users could unknowingly also send the equivalent BIP110 coin to an identical address on the BIP110 chain— or vice versa.

It’s difficult to estimate at this point how much the forkcoins will be worth, or even if they will be worth anything at all. The lack of interest in buying BIP110 coins via fork future contracts does suggest there may not be much interest to buy them after a split either. But if you nevertheless want to be sure you’ll receive BIP110 coins if there are any, it’s probably best to self-custody your BTC (have access to your private keys), and don’t send any transactions until the dust settles and there is more clarity on how to proceed.

Aaron van Wirdum is the former Editor-in-Chief of Bitcoin Magazine and author of The Genesis Book: The Story of the People and Projects That Inspired Bitcoin. Follow him on Nostr.

This post Bitcoin’s BIP110 Moment: Three Possible Scenarios first appeared on Bitcoin Magazine and is written by Aaron van Wirdum.

Bitcoin Magazine

The End of the Closed-Source Era Is at Hand: Obscurity Was Never Security

Over the last few days, people who were trying to do everything right lost their Bitcoin. They bought a respected hardware signer, generated a seed offline using that device, and trusted the device to do the one thing a signer exists to do: produce a number no one else can guess. The Coldcard did not. A preprocessor guard that checked the wrong thing had quietly routed seed generation to a weak software PRNG (pseudorandom number generator), MicroPython’s Yasmarang, instead of the hardware entropy source. On some models the effective entropy collapsed to around 40 bits. The flaw shipped in March 2021 and sat in publicly readable firmware for more than five years. Attackers swept 500 addresses before anyone understood why; within days Galaxy Research’s tally reached 4,585 addresses and nearly $90 million; the attack is ongoing as of the date of this article.

Coinkite’s working assumption, with wide agreement on X, is that someone used AI to comb the publicly available firmware to find the bug. Whether or not that’s how this attacker found it, the next one will. While an AI-assisted audit was run weeks before the theft, it found nothing (potentially due to the capabilities of the model, potentially due to the specific construction of the search). Since the attack started, researchers have shown several frontier models locating the same flaw in minutes from a single prompt. The code sat open to human review for five years and no human caught it.

Coinkite had moved its firmware from a free-software license to source-available terms, MIT with a Commons Clause, after Foundation Devices used the code in a competing product. You could read the source but not build a business on it. It changed nothing. The bug lived in code a machine could read regardless of what the license permitted; it entered the tree, in fact, in the very rewrite that stripped out the last of the GPL code. The license change didn’t increase protection; it merely changed the economics of finding the bug.

In the age of highly skilled AI, everything that is distributed is readable, or soon will be. Strip a binary of its symbols, run it through a decompiler, and out comes the pseudo-C that greets anyone who has opened Ghidra: nameless variables, flattened control flow, functions labeled FUN_00401a20. Unreadable to most people. That high barrier to human understanding was the entire security premium of “closed source.”

A compiled program has no choice but to tell the truth. Code that stays encrypted cannot run. At the moment of execution the processor must receive the actual instructions, so whatever the program does, it hands the machine a complete and exact account of how to do it. The information is all there in the machine code. Obfuscation does not, and cannot, remove it.

If reading a binary sounds too hard for a machine to master soon, weigh it against what machines are already doing to problems far harder. Reading a binary is analysis: every fact you need is in front of you, and the work is extraction. Mathematical invention is another order of difficulty, because it demands an object no one has ever seen. At 02:19 UTC on July 20th, Levent Alpöge, a mathematician working with Anthropic’s Claude Fable 5, posted a counterexample to Keller’s Jacobian conjecture, a problem open since 1939 and hard enough to sit on Stephen Smale’s list of challenges for the twenty-first century. Generations had tried it. The disproof is three polynomials in three variables. Lean verified it within hours, and it is short enough for anyone to confirm in a computer-algebra system in about a minute.

The Jacobian fell in an afternoon, while the questioner was apparently watching the final match of the FIFA World Cup. In May an OpenAI model toppled the Erdős unit-distance conjecture, a question open since 1946; in late July a 30-year-old graph-theory conjecture fell to four prompts; between them came the Jacobian disproof and a run of other results that had stood for decades.

Set that pace beside the modest task of reading machine code already sitting out there on the Internet. Today’s models handle source and decompiler output better than raw bytes, so a fully closed binary keeps a thin margin. That margin is a cost speedbump, and it is eroding at the speed you are watching everywhere else. Betting security on how long it lasts means betting against a clock that is only speeding up.

The same capability that finds your entropy bug reads your proprietary method. This is the quieter casualty, and it impacts companies that never thought of themselves as exposed to open-source anything. Trade secrecy in shipped software was always just obscurity in a suit. The law has said so for as long as trade-secret law has existed: reverse engineering a product you lawfully possess is fair play, and therefore a secret survives only while that reverse engineering stays expensive. When the cost of extraction falls to a subscription and a prompt, the secret embodied in the code you hand your customers stops being one. Your clever algorithm, your undocumented format, your edge in the binary: legible to anyone who cares to look, on a timeline increasingly measured in minutes.

None of this necessarily makes open source safe. Heartbleed hid in the most widely deployed TLS library on earth for two years, because visibility without funded attention finds nothing. The xz backdoor showed that the open contribution model is itself an attack surface, one a patient adversary can walk through with a friendly face and two years of good commits. While openness once was a shield, it is no longer. What it does buy is reviewers who are permitted to look, builds which can be independently reproduced and verified, an exit when a vendor dies or turns, and acknowledgment that this all will happen whether you like it or not.

Now we must assume every line shipped will be read by someone who wishes harm, because it will be. The defender holds one structural advantage the attacker never will: time. You can turn the same frontier models on your own code before release, in the space between commit and ship, while the attacker waits for a binary that does not yet exist. Make your builds reproducible, so it ties back to the source and the source can be checked. Design to fail closed, and keep the trusted core small enough that one bug cannot take everything. For the specific business of holding Bitcoin, learn the lesson Coldcard is teaching in real time: own the entropy you cannot afford to have guessed, keep the secure element minimal and behind a published interface, and spread your keys across independent implementations, so that no single device, and no single vendor’s mistake, is the whole of your exposure.

For Bitcoin the stakes are unforgiving in a way they are not elsewhere, since mere knowledge of the private keys grants possession. The entropy bug has left permanent scars. Patching the generator does nothing for the seeds it already produced; a weak keyspace stays sweepable forever, and disclosure hands the attacker the recipe. We have watched this before. The Milk Sad vulnerability in the libbitcoin explorer tool, bx, seeded private keys from a 32-bit value, and attackers were draining the wallets it produced before the flaw was ever made public. Attackers keep their own schedule, invited or not. For money that cannot be clawed back, “findable eventually” is a synonym for “gone eventually.”

Bitcoin never trusted obscurity. The protocol is open, its rules checkable by anyone, its security resting not on secrets but on mathematics and incentives that hold in full view. The hardware and software we build around it deserve the same standard, because the alternative is no longer on the table. The choice was never open or closed. It was disciplined or exposed.

The broader lesson of this Coldcard situation is that having closed source software is like having a seed generated by a broken Coldcard; it looks good but it’s fundamentally built on sand. Everyone can read the code — the only question left is whether you acknowledge that fact, or you and your users learn it the way Coldcard’s users did, one drained address at a time.

This is a guest post by Colin Crossman, who is the Wyoming Deputy Secretary of State. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

This post The End of the Closed-Source Era Is at Hand: Obscurity Was Never Security first appeared on Bitcoin Magazine and is written by Colin Crossman.