Bitcoin Core is ending the year-long wait for security patches that a language model can find again in a single prompt. A change to the project’s security disclosure policy, merged on October 22, creates an “easily discoverable” class of vulnerability and instructs maintainers to ship a point release and a public advisory “as soon as possible” — bypassing the standard embargo that keeps a medium- or high-severity bug secret for roughly a year.
The trigger is blunt. Maintainers are fielding more reports for bugs that keep getting rediscovered, because language models have lowered the effort needed to find them. Antoine Poinsot, a Bitcoin Core contributor at Chaincode Labs, announced the change on the Bitcoin Development Mailing List the same day the pull request was merged.
“We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered,” Poinsot wrote. “This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes.”
Why a Year-Long Embargo Stopped Buying Anything
Bitcoin Core’s previous policy tied disclosure timing to severity. Low-severity bugs went public two weeks after the next major release shipped. Medium- and high-severity bugs stayed private until two weeks after the last affected release reached end of life — a window the policy itself describes as “approximately a year after a major version containing the fix was first released.”
That timetable existed for a reason. Bitcoin Core is the reference implementation running the majority of Bitcoin’s nodes, and node operators upgrade slowly. A long embargo was meant to give the network time to patch before details went public. The tradeoff was that fixes generally were not backported, so an operator on an older release waited for the next major version, which the project aims to ship roughly every six months.
The caution is structural rather than accidental. Consensus changes such as Bitcoin’s Taproot upgrade move through a slow, conservative path precisely so operators can adopt them on their own schedule.
“Because of the nature of our project, coupled with a slow upgrade culture, our security policy favours a longer embargo period,” Poinsot wrote. “This generally means security fixes can’t be backported, and only become available with users along with the next major release.”
AI breaks that tradeoff. If a bug can be rediscovered with a trivial LLM scan, hiding it buys nothing, because the flaw is already within reach of anyone holding a chatbot. “For these issues that are easy to find, this is the wrong tradeoff. The embargo period achieves little but it delays the availability of a fixed release,” Poinsot wrote.
What the New “Easily Discoverable” Class Actually Changes
Under the revised policy, the disclosure clock now has a third setting. A vulnerability can be flagged “easily discoverable” during triage — defined as one that “can be discovered with minimal effort, such as through a simple LLM prompt.” The label is not limited to AI-found bugs: it turns on how little effort rediscovery takes, not on which tool did the finding.
For those bugs, the response changes on every axis. Instead of a single fix landing in the next major release, maintainers will backport a fix to every currently maintained major version — three branches under Bitcoin Core’s rule of supporting its latest three releases — and cut point releases as fast as they can. A security advisory publishes alongside the patched software.
The severity ladder still governs everything else. Low-severity bugs stay on the two-week schedule. Medium and high stay on the roughly one-year clock. Critical bugs — the ones that could steal coins at the protocol level, inflate the supply, or permanently split the chain — remain outside the standard policy and are handled case by case, as they always were.
That carve-out exists for good reason. In Bitcoin Core’s history, the inflation bug disclosed as CVE-2018-17144 in September 2018 was the kind of flaw that justified special handling: it could have allowed coins to be created outside the issuance schedule. The new “easily discoverable” route does not touch that tier — a critical bug will still get an ad hoc response shaped around the risk to the whole network.
Two Weeks, a Year, or “As Soon as Possible”
The change is easiest to read as a collapse in the disclosure window. A medium-severity bug fixed today would normally stay private for about 52 weeks, disclosed only two weeks after the last affected release reached end of life. The same bug, once flagged easily discoverable, ships as a point release “as soon as possible” with its advisory. That is the difference between a year and, in the maintainers’ own framing, however long it takes to write, review, and test a targeted patch.
The backport commitment is the other half. Before the change, a fix generally did not reach users on an older maintained branch; it arrived with the next major release. Now an operator on an older supported version can take a targeted point release without adopting every feature and behavior change in the newest major version. For a network where upgrades are slow and deliberate, that is a material change to how quickly a patch can actually land.
The Risk the Maintainers Themselves Flagged
The faster route has a cost, and Poinsot said it plainly in the pull request. “This is particularly important as under this policy, mitigations won’t have as much ‘bake time’ in development branches before being released to users,” he wrote. A fix that ships in days spends less time in review and testing than one that sat for months.
The discussion also split on whether disclosure should move even faster. Some contributors argued that opening a fix’s pull request can itself tip off attackers, because it is cheap to watch the repository automatically, so disclosure may need to come no later than the patch, or ahead of it with mitigation guidance. A different contributor proposed shipping fixes with a discretionary or delayed advisory. Poinsot rejected that, writing that alerting users without details could trigger a rushed migration among operators who were never affected.
The exchange matters because it shows the new policy is a deliberate middle path, not an obvious one. The merged text keeps the advisory simultaneous with the fix and keeps full details, rather than a vague warning.
When the First “Easily Discoverable” Bug Lands
No vulnerability has been placed in the new class yet, so this is a change of process, not the disclosure of a live bug. The first real test arrives when maintainers flag something “easily discoverable” during triage and ship point releases across the maintained branches with a simultaneous advisory.
The wider signal is that AI-assisted bug hunting has already forced the Bitcoin ecosystem to move. Core Lightning told node operators earlier this year to upgrade or disconnect after AI-generated vulnerability reports proved correct. Bitcoin Core’s policy change is the reference implementation making the same calculation at the protocol’s base layer: when rediscovery is cheap, secrecy buys little, and the only thing a long embargo delays is the fixed release.
For node operators, nothing changes today. The upgrade cadence stays the same. The difference arrives the next time a bug qualifies as easily discoverable, when a patch and its advisory land together with less notice than the network has ever had.
Disclosure: This article does not represent investment advice. The content and materials featured on this page are for educational purposes only.
