dpc

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.

AI, Tau, and Software Architecture

2026-07-24T00:00:00+00:00

I recently joined a podcast to talk about my shift from AI skeptic to what I jokingly call “AI psychosis mode.” We discussed building Tau</a>, treating coding agents as powerful tools that demand equally serious safety measures, and why good software architecture matters even more when AI can produce code so quickly.
We also touched on boutique software: small, focused tools shaped around their users rather than the broadest possible market. </iframe>

He Went to the Slop Side

2026-07-22T00:00:00+00:00

The Slop Side of Code is a pathway to many abilities some consider to be… unnatural. </blockquote>
Not much we can do now. Should have stopped or warned him while it was still early. It started so innocently. He was only doing Slop recreationally, in small doses</a>. He thought he could stop at any time... just review every change and you're safe, right? Yeah, right. Now he's gone, and this post is probably AI-generated.
Stop crying. Here, have some em dashes to wipe your tears with: —, —, —.
I will tell you why. He told me. The Slop made him feel young again. Like he was a noob and didn't know what he was doing at all. Everything felt so new again—full of questions, challenges, and possibilities. And he just couldn't resist the power. To command these... golems—or clankers, as he called them—was to have a personal army at his disposal. I know—unnatural, foul creatures they are. But he said he took a liking to them... He found them... delightful—hah!—and funny. They were funny when they were impressive, and they were funny when they failed spectacularly. Their unpredictability was an irresistible counterpoint to the hard, cold determinism of everything he was used to.
And now he has his own harness to command them</a> and methods to control and bind them</a>, and he is using his newly acquired powers to rapidly deepen his integration with them</a>.
So that's why I'm here. To warn you that he went Full Slop. And I don't think he is ever coming back. He swears he's fine and has never been better, but I think his demise is certain. It's just a matter of time.

LLM Reviews in cargo-crev

2026-04-12T00:00:00+00:00

There has been lots of chatting about software supply chain security recently, motivated by popular package exploits.
Well, I have some relevant news: cargo-crev</a> now supports LLM-assisted code reviews. Go try it!
Read on to get more information and background.
History
#</a> </h2> Just a few weeks ago I was reading some articles about new LLM models finding non-trivial security issues, and Linux kernel and curl developers admitting that after a deluge of mostly worthless slop security reports they used to complain about, now they tend to receive actually worthwhile AI-assisted bug and security reports. It reminded me about cargo-crev</code> and I realized that AI can actually fill the gap that made me doubt it. I'm not trying to overhype LLMs. But the fact is that they can do, and in high volume, what developers themselves have no time for: the 90/10 security scanning that was otherwise quite hard to automate. An LLM can easily and reliably check if a code version published on https://crates.io matches the code published in git. An LLM can easily scan build.rs</code> and the rest of the code and look if anything looks out of place. It is actually very hard to hide key-stealing malware in a package that was supposed to format units, etc. Especially in Rust, doing things that are wrong or out of place creates a lot of noise, making such code easy to notice, even by an LLM reviewer. It might not be a silver bullet, but it is definitely better than doing nothing. How to use it#</a> </h2> Note: In the initial release cargo-crev</code> supports only Claude Code agent. If you're interested in adding support for other coding agents, it should be relatively easy — most scaffolding is already there. Feel free to chat and create a PR. Since version 0.27 cargo-crev</code> has a built-in review loop. cargo crev ai review-loop --iterations 10</code></pre> which will start the agent 10 times, each time selecting and reviewing a single dependency. The agent will produce&update a single shell script that can be used to conveniently review and sign all reviews. While the above is meant as a standard mass-review flow, the core built-in agent review skill is available as an output of: cargo crev ai skill review</code></pre> and it should be easy for anyone to modify it and/or build their own LLM-assisted workflows. How it works#</a> </h2> The core change is that Crev's reviews now have fields to indicate that an LLM was used for the review</a>. The rest is just relatively minor functionality to make producing LLM reviews convenient end to end. For people skeptical of LLMs, options to ignore LLM-generated reviews have been and will be added where appropriate. You can just ignore the slop reviews if you don't trust them, fine with me. How well it works#</a> </h2> While working on this feature and testing it myself, I have produced quite a few LLM-assisted reviews</a>. Judge by yourself. To me these meet the bar of being useful. And they turned some spare capacity from my Claude subscription into something that I otherwise would not be able to do myself. Summary#</a> </h2> This is only an initial attempt at harnessing the AI in cargo-crev. There still might be lots of things to improve and extend, but we have to start somewhere. If you like the idea and find it promising, I encourage you to try it out, give some feedback, and submit improvements.