- Bitcoin Core developers have merged a change to how security flaws are handled, ending long secrecy periods for bugs an attacker could rediscover with one AI prompt.
- Fixes for flaws judged easy to find will now be backported and shipped straight away rather than held back for months.
- Nobody has published a test for what counts as easy to find, so that judgement sits with the developers making it.
Bitcoin’s main software has kept serious flaws quiet for months at a time, on the reasoning that a bug nobody knows about is a bug nobody can use. That reasoning has just been narrowed. Core developers have merged a policy change covering flaws a chatbot could turn up in a single prompt.
If you run a node, or a wallet that keeps its own copy of the , the gap between a fix being available and the flaw becoming public knowledge is about to get much shorter. Patches will reach you faster. So will the information an attacker would need. Putting off an update for a few weeks used to be a reasonable thing to do, and it is becoming a less reasonable thing to do.
The embargo, and why bitcoin’s ran so long
Bitcoin Core is the reference implementation of bitcoin, the software that the large majority of nodes on the network actually run. When someone finds a flaw in it, the project does what most serious software projects do: it handles the report privately first.
That private period is the embargo. The finder tells the maintainers rather than the internet, the maintainers write a fix, and the details stay unpublished until enough people have installed it. The logic is straightforward. Publishing a flaw before a patch exists hands a working attack to anybody who reads the announcement.
Bitcoin’s embargoes have tended to be unusually long, sometimes running for months or longer. There is a structural reason for that. Nobody can push an update to a decentralised network. Thousands of independent operators each decide when to upgrade, and some of them run the same binary for years, so the window needed before disclosure is genuinely wider than it would be for a product that updates itself overnight.
The cost of that caution was always the same: a known flaw sitting unfixed in live software, with a small group of people aware of it and everyone else not.
What the new policy does
Under the merged change, flaws described in the reporting as “easily discoverable” come out of that process. Fixes get backported to supported versions and a release goes out immediately, rather than waiting on an embargo clock.
The trigger is the one the industry has been bracing for. If an off-the-shelf model pointed at the codebase can surface a bug in one prompt, then keeping it quiet protects nobody, because the only thing standing between an attacker and the flaw is the few minutes it takes to ask. CoinDesk reports that AI tooling turned up hundreds of bugs in bitcoin code over the summer, in several cases before human reviewers had found them. Decrypt describes the same shift in the same terms.
We could not reach the merged policy text itself, so the wording above and the volume of AI-found bugs both come from those two write-ups rather than from the repository.
The change is less dramatic than it sounds in one respect. It does not abolish embargoes. Hard-to-find flaws, the kind that take a specialist weeks of work to spot, presumably still get the old treatment. What has gone is the assumption that secrecy is free.
What it leaves open
The obvious question is who decides, and on what basis. “Easily discoverable” is a judgement, and the published reporting does not describe a test for it. A bug that one model finds instantly might take another model a dozen attempts, and a developer sitting on a borderline case has to make a call with no published yardstick behind it.
Elsewhere in software, the direction has been the same for years. Google’s Project Zero works to a 90-day disclosure deadline and shortens it sharply for bugs already being exploited. The Linux kernel security team caps its embargoes at around a week. Against that, a bitcoin embargo measured in months was always the outlier, and this change moves the project closer to normal practice rather than away from it.
It is also unclear what advance notice, if any, large operators such as pools and exchanges receive under the new arrangement. Those are the parties with the most at stake and the fastest upgrade paths, and how they are treated changes who carries the risk in the hours after a release.
What to watch
The first release that actually uses this. The policy only means something once a flaw is shipped under it, and that release will show how much detail gets published alongside the fix and how quickly node operators move.
Beyond that, upgrade rates. Node version data is public, and the share of the network still running old builds a month after a security release is the number that tells you whether faster disclosure is making bitcoin safer or simply making the unpatched more exposed. If you hold coins in a wallet you control, the practical version of all this is unglamorous and sits in our self-custody guide: keep the software current.