Bitcoin Core is right: when an AI can find the bug, secrecy is theater

What good is a secret that any chatbot can regenerate in one prompt? That is, in essence, the question Bitcoin Core just answered, and we think it answered it correctly.

On Thursday, October 22, the project merged a change to its security policy, written by Chaincode Labs developer Antoine Poinsot. Until now, Core graded each vulnerability by severity and timed disclosure accordingly. Low-severity flaws were revealed two weeks after the next major version shipped. Medium and high ones could stay hidden until two weeks after the last affected release reached end of life, a wait that can stretch to about a year. Now maintainers can label a bug "easily discoverable" during triage. That label covers a bug that can be found with a simple LLM prompt. Such a bug gets a fix backported to every maintained version, a point release as soon as possible and a security advisory with some details. Critical bugs stay outside the standard policy and are handled case by case.

The embargo was a bet on difficulty, and the odds changed

A long embargo only works if attackers are unlikely to find the hole on their own. Quiet patching buys time for node operators to upgrade before anyone learns where the weakness is. Poinsot's own diagnosis, as CoinDesk quotes him, is that LLMs have "drastically" lowered the bar to find certain classes of issues or to identify covert fixes. That second part is the underrated one. A silent patch is itself a clue, and a model can read a diff.

So for this class of bug, the embargo protects nobody except the attacker, who already knows. Meanwhile honest users sit on unfixed older versions waiting for a major release. The policy says it plainly: "The embargo period achieves little but it delays the availability of a fixed release."

The evidence says this is not hypothetical

Consider what happened this summer. A volunteer group of 16 developers, the Bitcoin Red Team, ran AI models across 390 Bitcoin projects in about a day and logged 4,962 findings, 85 of them critical, according to CoinDesk. Not all of those findings were reproduced (one report says only around a fifth had been at that point), so the number should be read with that caveat. Still, within days a flaw in BTCPay Server that the group had reported privately was being exploited on live merchant servers. Private reporting did not outrun the attackers.

The wider picture points the same way. A Cloud Security Alliance research note argues that the classic coordinated disclosure model, with its typical 90-day window, was designed for human researchers working at human speed. We read the Bitcoin decision as a concrete case of that argument.

Transparency has a price, and it is worth paying

The change is not free. Poinsot admits that faster fixes get less "bake time" in testing. That is a real risk, because a rushed patch to software securing a huge network can go wrong. The alternative proposed by developer Antoine Riard, shipping fixes without an advisory in some cases, was rejected, and we agree with the rejection. Poinsot argued that alerting users without details could trigger rushed migrations by people who would not even be affected. Half-secrecy gets you the panic without the information.

There is also a fair concern about the line itself. No bug has yet been flagged under the new rule, so, as Crypto Briefing notes, the open question is how consistently maintainers will decide what counts as "easily discoverable." A vague label could become a loophole in either direction. Our view is that the criterion is honest, because it depends on how easy a flaw is to find rather than on which tool found it.

What other projects should take from this

The lesson is not "disclose everything immediately." Hard-to-find bugs still deserve time, and Core keeps its severity schedule for them. The lesson is that the default assumption has flipped. Projects should now ask whether a bug can be cheaply rediscovered, and if so, treat patch speed as the priority rather than discretion. Critical open-source projects with slow upgrade cultures have the most to gain, since they have the most to lose from a long exposure window.

Our verdict: Bitcoin Core made a pragmatic and slightly uncomfortable move, and it is the right one. Operators should watch for point releases and advisories and be ready to upgrade quickly. Everyone else maintaining widely used code should look at their embargo rules and ask which of them still protect users, and which only protect the habit.