Bitcoin Core developers merged a security policy change on Thursday. Vulnerabilities that a Bitcoin node can hand to any language model in a single prompt will no longer be hidden for months. Embargoes on medium and high severity bugs used to run for about a year, and now the fix ships right away.
The reason is in the numbers. According to CoinDesk, AI turned up thousands of potential flaws in bitcoin projects this summer, and some of them reached real attacks before humans could react.
How the old embargo worked
Core used to grade every vulnerability by severity and set the disclosure date from that grade. Low severity flaws were published two weeks after the next major version shipped. Medium and high ones stayed under embargo until two weeks after the last affected version reached end of life, which means months, sometimes close to a year.
The logic was simple. A fix ships quietly, node operators upgrade over time, and only then does the world learn what was patched. An attacker has no reason to hurry because they do not know where the hole is.
That scheme rested on one assumption, that finding a bug is hard. It no longer holds.
What exactly changed in the rules
During triage, Core can now flag a bug as easy to discover. The test is literal, and it can be found with "a simple prompt to an LLM". For those bugs the fix is backported to every version the project still supports, shipped in a point release "as soon as possible", and paired with a public advisory carrying some details.
"We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered. This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes."
- Antoine Poinsot, Chaincode Labs developer, from his proposal to change the Bitcoin Core security policy
The policy text calls the old embargo "the wrong tradeoff" for such cases because it achieves little, yet it delays the fixed release. The cost of the new approach is stated just as openly. Fixes will get less testing time before they reach users.
The summer that broke the assumption
The scale is clearest in the Bitcoin Red Team case. Sixteen volunteer developers ran AI models across 390 bitcoin projects in about a day in late July and logged 4,962 findings. Eighty-five of them were critical.
Consequences followed, not theory. Within days a BTCPay Server flaw the group had reported privately was being exploited on live merchant servers. The attacks drained the Lightning nodes merchants use to take small payments. Core Lightning, one of the main implementations of that network, told operators to disconnect after AI-generated reports to its small team turned out to be real.
Coldcard and 594 BTC in 25 minutes
The biggest loss of the summer came from a bug no AI needed to find. A flaw in Coldcard hardware wallet firmware sat dormant from 2021, and on July 30 attackers drained 594 BTC in 25 minutes. Four sweeps together came close to $114 million.
When Coldcard shipped its fix, the company said AI had helped catch more bugs along the way. For people who own hardware wallets that is an uncomfortable takeaway. Firmware that is five years old can hide a hole anyone with a chatbot subscription can find today.
The fight over "silent" fixes
Not every developer agreed with the new approach. Antoine Riard, a longtime bitcoin security researcher, wanted Core to keep the option of shipping a fix without an advisory and holding details back case by case.
Poinsot refused. Alerting users to a vulnerability without details, he argued, creates needless risk, because people who are not affected would rush into a migration. A quiet release that is easy to spot in the code diff only draws the attention of attackers.
That clash left the project with a set of rules.
- easy-to-find bugs get fixed in all supported branches at once
- the release ships with an advisory that carries part of the details
- the "easy" call is made during triage, not after the fact
- hard vulnerabilities an AI cannot reproduce stay on the old timelines.
What it means for node runners and BTC holders
For anyone running a node the rule is plain. Security updates may now come more often and with less warning, so release notes deserve a closer read. A shorter bake time raises the odds that the fix itself carries a regression.
For ordinary bitcoin holders who do not run a node, nothing changes, money does not vanish because of a disclosure policy. But the summer's 594 BTC showed that risk lives in third-party code they never see. That is why we at Kurslog suggest keeping the amount for everyday exchanges apart from long-term savings.
No bug has been flagged under the new rule yet. But a secret a model regenerates in one prompt does not stay secret for long, and Core has now admitted it in its rules instead of a developer chat.
Comments
Your email address will not be published. Required fields are marked *