Bitcoin is under siege

2026-08-07T00:00:00+00:00

Bitcoin is under siege, and you should pay attention because your software ecosystem is likely to be next.

Bitcoin is first because it is an easy place to search for vulnerabilities and exploiting them can be extremely profitable. Most of its software is public, and a working exploit can move money immediately and irreversibly.

The recent COLDCARD hack</a> made the threat impossible to ignore. A years-old firmware bug weakened wallet seeds and put funded wallets directly at risk. Coinkite suspects AI-assisted review found it, though there is no public proof and its own earlier AI review missed it.

The details of that particular bug are less important than the reaction. The exploit demonstrated the stakes, while the scale of what AI could do changed the threat model.

The ingredients are readily available. Source code, including its complete history, is already public. For producing code, I still get more reliable results from frontier models. But capable open-weight models can also be run locally, beyond a provider's guardrails, rate limits, or security policy. Point them at old releases, run them in parallel, and ask them to think like attackers.

The defensive response was immediate. Volunteers formed the model-assisted Bitcoin Red Team, while OpenSats launched Code RED</a> as a priority funding path for red-teamers, including reimbursement of LLM token costs.

According to a public update from the team</a>, the first numbers were staggering: 4,962 candidate findings across 390 projects in 27.5 hours, with 85 labeled critical and 635 high severity. These were the team's labels, not independently audited results or 4,962 confirmed vulnerabilities. The team reported reproducing only about a fifth at that point, and did not report that Bitcoin Core itself was affected. Even after a very large discount, the result is alarming.

The mental model changed almost overnight:

A switch from "it's irresponsible if you didn't review your clanker's code" to "it's irresponsible if a clanker didn't review your code"</a> was fast and dramatic. </blockquote>
Affected maintainers are now scrambling to reproduce private reports, understand their impact, write patches, coordinate disclosures, and ship emergency releases. There is no clear end in sight. Finding suspicious code can now be massively parallelized; triage, coordinated disclosure, fixes, and releases remain maintainer bottlenecks. Even when a patch is ready, slow GitHub Actions jobs and release infrastructure can still hold it up.
Bitcoin is probably only the canary. It is an obvious early test case: the code is public and verifiable, it operates in an adversarial environment, and finding a bug can be worth millions. Avoiding bugs is not some secondary quality goal here.
Yet a short burst of machine-assisted review found a mountain of suspicious code. What should we expect from the many codebases with weaker incentives, less scrutiny, and failures that cannot be cashed in immediately?
This also punctures some human pride. "I wrote this code by hand" was never the assurance people pretended it was. Much of this code was human-written, and some bugs had survived years of human review. Now that adversarial review can be applied cheaply and en masse, we are discovering how good that work really was.
Using clankers to produce code, and independent clankers to review it, is quickly becoming non-optional. Humans remain responsible for the result, but manual authorship is not a security property. Attackers have these machines. Defenders need to use them continuously, because "nobody noticed this for years" is no longer a security argument.

dpc - bitcoin

Bitcoin is under siege