Bitcoin Core Adds 'Easily Discoverable' Tier as LLMs Break Embargo Model
Chaincode Labs developer Antoine Poinsot announced a new 'easily discoverable' vulnerability tier for Bitcoin Core, accelerating patch timelines for bugs that LLMs can surface with a simple prompt.
Chaincode Labs developer Antoine Poinsot has proposed an update to Bitcoin Core's security disclosure policy to account for a hard reality: LLMs have made certain vulnerability classes cheap to rediscover, and long embargo periods no longer protect anyone from them.
Key takeaways
- Bitcoin Core is proposing an "easily discoverable" vulnerability category for flaws that can be found "with minimal effort, such as through a simple LLM prompt," with patches backported immediately to all maintained major versions and security advisories published alongside the release.
- The change acknowledges that the old long-embargo model assumed rediscovery required expertise. LLMs killed that assumption.
- Node operators on maintained versions should expect more frequent out-of-band patch releases for this class of bug and must treat minor version upgrades as a security obligation.
Poinsot announced the proposed update to the Bitcoin Development Mailing List on Thursday, October 23, 2026, with the full policy text in GitHub PR #1281. The core problem he identified: for a certain class of software flaw, keeping the fix secret buys defenders less time than it costs them in delayed patch availability.
"The embargo period achieves little but it delays the availability of a fixed release," Poinsot wrote in the PR. "We are therefore updating our policy disclosure to accommodate those."
What the Proposed Policy Actually Does
Under the prior framework, security fixes generally shipped only with the next major Bitcoin Core release, with disclosure following weeks or months later depending on severity. That model assumed rediscovering a known-but-secret vulnerability required domain expertise and a motivated attacker willing to diff commits manually.
The proposed "easily discoverable" tier breaks from that assumption. Any flaw classifiable as findable "with minimal effort, such as through a simple LLM prompt" would get a fix backported to all currently maintained major versions immediately, with the security advisory published at the same time. There is no long embargo and no waiting for the next major release.
The existing severity tiers would remain in place. Low-severity bugs are disclosed two weeks after the major release containing the fix. Medium and high vulnerabilities are disclosed two weeks after the last affected release hits End of Life, typically around a year post-fix. Critical bugs, which would threaten Bitcoin's fundamental integrity, stay outside the standard policy and get handled on an ad-hoc basis.
Luke de Wolf, co-host of the Bitcoin Infinity Show and author of Defending Bitcoin, offered a candid reaction: "I've disagreed with Antoine's approach to security in the past, but this is a good update."
The Threat Model Changed, and This Policy Reflects That
The old embargo logic was sound when it was written. A determined attacker trying to rediscover a known vulnerability had to identify the relevant commit, understand what it patched, and possess enough cryptographic and systems expertise to reconstruct the exploit. That barrier bought defenders meaningful time.
LLMs collapse that barrier for a specific subset of flaws. A motivated non-expert can now prompt their way to a rediscovery in minutes.
Holding the embargo open doesn't stop that attacker. It only delays the patch getting to honest node operators. AI-assisted security tooling is reshaping the threat model in real time.
Poinsot is not capitulating to AI hype here. He is correctly recognizing that the threat model changed and updating policy to match. The "easily discoverable" classification is at developer discretion during triage, not hardcoded to any single tool, which gives the policy flexibility as LLM capabilities continue to change.
The governance signal is worth noting separately. Bitcoin Core, a leaderless open-source project with no foundation or executive team, is updating its security posture in response to a demonstrably changed environment without a political fight or a contentious fork. That is functional, low-drama technical stewardship. The contrast with altcoin projects that paper over vulnerabilities with foundation announcements and quiet patches is real.
For self-custody Bitcoiners, this matters directly. Running your own node and keeping it current is not optional housekeeping. Under the new policy, if your version falls off the maintained list, you lose coverage for the most time-sensitive class of fixes. The Bitcoin Core lifecycle page at bitcoincore.org/en/lifecycle/ shows which versions are still supported.
What Node Operators Should Do Now
The practical implication for anyone running Bitcoin Core on an older maintained release is more frequent out-of-band patch releases for "easily discoverable" bugs, not just annual major version updates. If you upgrade promptly, the new policy is a net improvement in your security posture. If you ignore minor releases, the new policy exposes you to a window you did not have before.
The falsifiable thesis here: this policy holds if the accelerated fix window closes exposure faster than it creates new attack surface. The trigger that breaks it is an "easily discoverable"-tier vulnerability exploited in the wild between triage and the patched release shipping. That would mean the faster disclosure cycle introduced a new race condition instead of eliminating one. That outcome would require a policy revision, and the Bitcoin Core community would need to revisit the tradeoff.
Watch the next few patch cycles. The new tier's real-world behavior will be visible in how quickly fixes ship and whether any pre-patch exploitation surfaces.
Sources
Frequently Asked Questions
Does this mean Bitcoin Core has a security vulnerability right now?
No. This is a governance update, not a disclosure of a specific flaw. The policy change reflects a shift in the external threat model, specifically LLMs lowering the bar for bug rediscovery, not a newly discovered weakness in the protocol itself.
What exactly qualifies as "easily discoverable" under the new policy?
Bitcoin Core defines the category as a vulnerability discoverable "with minimal effort, such as through a simple LLM prompt." The classification happens at developer discretion during triage and is not restricted to LLM-findable bugs specifically. The definition is intentionally flexible.
How does this affect node operators on older Bitcoin Core versions?
Under the old model, fixes for certain bugs waited for the next major release. Under the new model, "easily discoverable" fixes would be backported immediately to all maintained major versions. Operators on versions that have reached End of Life receive no coverage regardless. Check bitcoincore.org/en/lifecycle/ to confirm whether your version is still supported.
