Mentioned in This Article
1. Bitcoin Core security policy drops long embargoes for easy bugs
Bitcoin Core, the software that most of the Bitcoin (BTC) network runs on, will no longer hold back fixes for months when an AI tool could rediscover the underlying flaw. Maintainers merged an update to the project's security policy on Thursday, October 23, replacing embargoes that could last close to a year with faster patches and advisories for bugs judged easy to find.
The change is a direct response to how language models have altered bug hunting. Developers argue that when a simple prompt can surface a vulnerability, keeping it secret protects very little, while it delays the fixed release that node operators need.
2. What did the old disclosure rules say?
Until now, Bitcoin Core ranked vulnerabilities by severity and tied disclosure to the release calendar. Low-severity flaws were made public two weeks after the next major version shipped. Medium and high-severity flaws stayed under embargo until two weeks after the last affected version reached end of life.
The logic was protective. By shipping a fix quietly and explaining it later, maintainers aimed to shield node operators, the people who run the machines that validate and relay transactions, from attackers who might learn about the weakness before it was patched.
That approach rested on an assumption that finding a serious bug demands real skill and time. For years that was a reasonable premise, because understanding a large, security-sensitive codebase takes expertise that few people have.
3. Why AI changes the calculation
The spread of AI tools has weakened that assumption. Antoine Poinsot, a developer at Chaincode Labs who wrote the proposal, said Bitcoin Core has recently received more reports of vulnerabilities that are easy to rediscover.
He attributes this mainly to large language models, which lower the skill needed to find certain classes of bugs or to notice a quiet fix after it lands in the code. A fix committed without explanation can itself be a clue, since a model can be asked to compare versions and describe what changed.
In that environment, an embargo can give a false sense of safety. If several independent parties, or a single chatbot, can arrive at the same finding, the secret may not hold for the months the policy once assumed.
4. How will the new rule work?
Under the revised policy, the triage process can flag a bug as easy to discover, meaning one that could be found with a simple prompt to a language model. Fixes for those issues are backported to all supported versions and released in a point release as soon as possible. A security advisory accompanies the release and includes some details of the flaw.
Poinsot described the old embargo as the wrong tradeoff for issues of this kind. It postpones a patched release while achieving little, because the information it tries to protect can be regenerated by anyone willing to ask.
He acknowledged a cost. Fixes released this quickly will have less time in testing before they reach users, a period developers sometimes call bake time. Faster shipping therefore trades some review depth for a shorter window of exposure.
5. What did the summer's AI bug hunt reveal?
The policy change follows a busy summer. A volunteer group of 16 developers calling itself the Bitcoin Red Team ran AI models across 390 Bitcoin projects in about a day in late July. The effort logged 4,962 potential flaws, 85 of them rated critical.
Real incidents followed within days. A flaw in BTCPay Server that the group had reported privately was being exploited on live merchant servers, draining the Lightning nodes that merchants use for small payments. Separately, Core Lightning, a major Lightning implementation, told operators to disconnect after AI-generated reports sent to its small team proved valid.
The largest loss came from a bug that did not require AI to find. A flaw in Coldcard hardware-wallet firmware, dormant since 2021, let attackers drain 594 BTC in 25 minutes on July 30. Losses neared $114 million across four sweeps. When Coldcard released its fix, it said AI had helped uncover additional bugs.
6. Why disclosure timing matters in open-source software
Responsible disclosure is a long-standing convention in software security. A researcher or maintainer who finds a flaw tells the project privately, the project prepares a fix, and details become public only once users have had a chance to update. The delay is meant to keep attackers from exploiting a hole that has been described but not yet closed.
Bitcoin Core adds a complication, because its code is public and every change to it is visible. A patch that is merged openly can reveal the shape of the vulnerability it addresses. Projects in this position have often tried to describe fixes in neutral terms, or to batch them into scheduled releases, so the change does not stand out.
Those habits made sense when reading code for weaknesses was slow, specialised work. The new policy reflects a judgment that, for a growing class of bugs, the habit now adds delay without adding secrecy.
7. What a point release is, and why it matters to node operators
Bitcoin Core publishes major versions on a regular schedule, with smaller point releases in between that carry targeted corrections. A point release is the vehicle the new policy relies on, since it lets maintainers ship a fix without waiting for the next major version.
Node operators then decide when to install it. Because the network has no central authority that can force an upgrade, security depends on enough operators updating promptly after an advisory appears. A faster advisory therefore asks more of them, and it explains why clear, detailed notices are part of the policy rather than an optional extra.
The less testing time that Poinsot acknowledged is the counterweight. A rushed patch to software that secures real funds is itself a source of risk, so the project is weighing the danger of a known, easily found flaw against the danger of an imperfectly tested fix.
8. What the incidents say about the wider ecosystem
The summer's episodes touched components that sit around the Bitcoin base layer rather than the core protocol. BTCPay Server is payment-processing software used by merchants. Lightning nodes are the systems that route small, fast payments on top of Bitcoin. Hardware wallets are dedicated devices designed to keep private keys offline.
Each of these has its own developers, release cycles and disclosure habits, which means a single policy at Bitcoin Core does not cover them. The examples show attackers moving quickly once a weakness is known, as in the BTCPay Server case, where a privately reported flaw was exploited on live servers within days.
They also show that not every serious loss needs modern tools. The Coldcard firmware flaw had sat undiscovered since 2021 and was drained in a matter of minutes once found. The episode illustrates why developers want fixes in users' hands as soon as possible, whether the bug was spotted by a person or a model.
9. Where developers disagreed on transparency
Not everyone on the project wanted to go as far. Antoine Riard, a longtime Bitcoin security researcher, argued that Core should keep the option of shipping a fix without a public advisory, withholding details case by case.
Poinsot rejected that idea. His objection was that alerting users to a problem without explaining it could create unnecessary risk, for instance by prompting rushed upgrades among users who would not have been affected, and by signalling to attackers that something valuable had been fixed.
The exchange shows how contested the balance between secrecy and transparency remains in a project where an error can touch a network holding a vast amount of value.
Supporters of the change point out that it matches how information now spreads. If a vulnerability can be reproduced from a one-line request to a chatbot, then withholding the fix leaves users exposed to anyone who happens to ask the right question, while the maintainers themselves stay silent.
Sceptics, represented in the debate by Riard, worry about tipping off attackers and about the pressure on users when advisories arrive without a full explanation. Their concern is that a policy designed for easy bugs could drift into covering harder ones, or that detail in an advisory could help an attacker faster than it helps a defender.
For ordinary users the practical effect is simple. Anyone who runs a node, or relies on software built on top of Bitcoin Core, should expect security announcements to arrive sooner than before and to come with enough explanation to judge urgency. Staying current with point releases becomes more important, because the gap between a fix being available and a flaw being widely understood is shrinking.
Poinsot's design tries to answer both camps by limiting the fast track to issues triage judges easy to discover, and by keeping the existing, slower process for the rest. Whether that line proves workable will depend on how consistently triage can tell the two kinds of bug apart.
10. What to watch next
No bug has yet been flagged under the new rule, so its first real test is still ahead. When one is, observers will be able to judge how quickly a point release reaches users, how much detail the advisory contains and whether the shorter testing window causes problems.
The broader argument behind the change is simple: a secret that any model can regenerate in a single prompt will not protect users for long. Whether other Bitcoin projects, and wallet and Lightning developers in particular, adopt similar rules is likely to be the next question for the ecosystem.