Bitcoin Core merged a change to its security disclosure policy on October 22, and the decision landed with less noise than a price candle but more long-term weight than most protocol debates. The short version: if a vulnerability is classified as something an LLM can rediscover easily, Core will now ship a fix as fast as possible across all maintained versions and publish a security advisory at the same time, instead of sitting on the bug for months under embargo.

Antoine Poinsot, the Chaincode Labs developer who wrote the change, framed it as a response to a shift that’s already happening. “We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered,” he wrote in the proposal, pointing directly at LLMs as the reason certain classes of bugs are now trivial to surface. The old logic was that a long embargo protected users by keeping attackers in the dark until node operators had time to upgrade. That logic assumed finding the bug required skill. Poinsot’s argument is that the assumption no longer holds.

The Data Behind the Panic

This isn’t a theoretical worry. In August, a volunteer group called Bitcoin Red Team ran AI models across roughly 390 Bitcoin-related projects and logged 4,962 findings in about 27.5 hours, including 85 critical issues and 635 high-severity ones. Within days of that sweep, a flaw the group had reported privately in BTCPay Server was being exploited on live merchant servers, draining Lightning nodes used for small payments. Core Lightning, one of the main Lightning implementations, told operators to disconnect after AI-generated reports turned out to be real.

I think the BTCPay detail is the one that makes Poinsot’s case for him. If an LLM can find the bug and someone else can weaponize it before a fix ships, the embargo stops being a shield and starts being a delay. “The embargo period achieves little but it delays the availability of a fixed release,” the policy text reads.

Speed Has a Cost

Core just traded one risk for another. Fixes for AI-discoverable bugs will get “less time for maturation” in testing before they reach users, and Poinsot said so himself in the proposal. A rushed patch that introduces a regression in consensus code is not a hypothetical nightmare. It’s the kind of thing that makes people nostalgic for slow embargoes.

There’s also the disclosure question. Antoine Riard, a longtime Bitcoin security researcher, wanted Core to keep the option of shipping a fix without a full advisory and withhold details case by case. Poinsot rejected that, arguing that warning users without details could trigger rushed upgrades from people who aren’t even affected. Riard’s position isn’t unreasonable. In my experience, the operators who run Bitcoin infrastructure are not a monolith, and a vague “patch now” signal can cause more operational churn than a precise disclosure.

The deeper issue is governance. Core just made a unilateral policy call on a security matter that affects the entire ecosystem, and the dissent was real but narrow. If the next AI-discoverable bug turns out to be more severe than expected, the decision will be relitigated in public with hindsight on the critics’ side.

The Old Model Was Already Broken

Core is finally admitting the embargo model was designed for a world that no longer exists. LLMs didn’t just lower the barrier to finding bugs. They collapsed it. A secret that any model can regenerate with a single prompt was never going to stay secret long enough for a year-long embargo to matter.

Poinsot’s change also keeps the severity tiers intact for everything else. Low-severity bugs still get disclosed two weeks after the release that contains the fix. Medium and high-severity bugs still stay under embargo until the last affected version reaches end of life. The new fast lane is narrow. It applies to bugs that are already cheap to find, not to the deep, hand-crafted exploits that the old process was built to contain.

And the broader context matters here. CZ weighed in on the same day, arguing that AI doesn’t need to crack Bitcoin’s cryptography to cause damage because leaked data and social engineering are already doing the job. Whether you take CZ’s framing or Poinsot’s, the conclusion is similar. The threat surface has moved, and Bitcoin’s security process has to move with it.

Summary

Bitcoin Core’s new disclosure policy is a bet that speed beats secrecy when the bug is already easy to find. The data from the Red Team sweep supports the bet. The dissent from Riard is a legitimate warning about what gets lost when testing windows shrink. I think the change is the right call for the narrow category it covers, but the real test hasn’t happened yet. The first time a fast-tracked patch causes a problem, this policy will be back on the mailing list. For now, the quieter story is the more important one: Bitcoin’s security process is being rewritten in real time by the same AI tools that are finding the bugs.