Bitcoin Core's Security Policy Rewrite: The Embargo Is Dead, and the Backport Is the Whole Point

CryptoRover • • Markets

On October 22, a pull request landed in the Bitcoin Core repository that changed no consensus code, altered no block size, touched no signature scheme, and produced no fork — soft or hard. It edited a policy document. And in doing so it quietly dismantled a disclosure norm the project had run on, informally, for roughly a decade.

The substance: a new vulnerability class called "easily discoverable." If a bug qualifies, the standard embargo does not apply. The patch ships immediately. The advisory ships with it. No quiet window. No staged rollout. No waiting for the last affected release to crawl toward end-of-life.

Six days separated proposal from merge. Antoine Poinsot, a Chaincode Labs–funded contributor, opened the discussion on October 16. Maintainer fanquake merged it on October 22. Five people are named across the thread. No independent security committee reviewed it. No foundation signed off. No stakeholder vote occurred, because there is no mechanism for one.

That is not a criticism. It is the architecture. And the architecture is the story.

Why a policy document outranks a patch

Bitcoin Core is not a company, a foundation, or a token issuer. It is the reference implementation of a protocol with a $1-trillion-class market cap attached to it, maintained by people who are paid, when they are paid at all, by research grants. Its authority is not legal. It is gravitational. Exchanges run it. Custodians run it. Wallet backends, Lightning implementations, indexers, and the settlement rails of every Layer 2 sitting on top of Bitcoin all inherit their assumptions from it.

That inheritance is why the mechanics of disclosure matter more than the mechanics of any single fix. A vulnerability in a wallet is a wallet problem. A vulnerability in the reference client is a coordination problem across an entire dependency graph — and the disclosure calendar is the clock that graph runs on.

The old calendar was built on one assumption: secrecy equals safety. Keep the bug quiet, develop the fix in the dark, backport it to every maintained branch, ship binaries, and only then tell the world. Classic coordinated vulnerability disclosure. It is a defensible model. It is also a model that assumes the defender can hold the secret, that the attacker cannot independently find it, and that the fix pipeline is fast enough to make the secrecy window meaningful.

All three assumptions have degraded. The third one has been broken for years, and almost nobody priced it in.

I spent 2017 reading over five hundred Ethereum ICO whitepapers for technical feasibility against marketing copy, and I found that roughly 85% had no viable roadmap behind the token. That experience hardwired a reflex into how I read any protocol announcement: ignore what the document says it does, and find what the document reveals it cannot do. 2017 called. It wants its lessons back. The lesson wasn't that disclosure is bad. The lesson was that disclosure theater is worse than silence, because it launders an unaudited artifact into a trustworthy one.

Bitcoin's culture ran the opposite direction — silence as a discipline. Which was correct for as long as it was honest about the trade it was making. The October policy rewrite is the first formal admission that the trade has stopped clearing.

What actually changed, and what did not

Strip the noise. The document lives in the policy layer, not the code layer. Nothing in src/ moved. No consensus rule shifted. Block space rules, script semantics, signature verification — untouched. What changed is a time function: when a vulnerability becomes public, and when a fix becomes available to people running something other than the tip of the development branch.

Under the revised schedule, four tiers now exist where three existed before. A newly created "easily discoverable" tier ships its patch and its advisory immediately, bypassing the standard embargo entirely. Low-severity issues still publish two weeks after the fixed release. Medium and high-severity issues still publish two weeks after the last affected version reaches end-of-life — which, given Bitcoin Core's roughly six-month major release cadence, means approximately a year after the fix first shipped. Critical issues remain adjudicated case by case, as they always were.

The tempting read is that this is a speed optimization. It isn't. Speed is the visible surface of a deeper structural repair, and the deeper repair is the part almost nobody has written about.

Here is the mechanical problem the old policy created. A long embargo means the fix exists in the development branch but cannot be discussed, cannot be published, and — critically — cannot be cleanly backported to older maintained branches without telegraphing what the backport addresses. So the fix sits. It sits for months. Users running the previous major version, which is a large population in every network that has ever existed, wait for the next scheduled release to receive a repair for a bug they were never told about.

That is the structural deficit the rewrite addresses. The old embargo did not protect users. It protected the secret at the users' expense. Compressing the embargo does not make Bitcoin safer in the abstract — it makes the fix deliverable to the population that needs it. Poinsot's own framing is unusually blunt on this point: the no-disclosure period, on these particular bugs, accomplishes very little beyond delaying the availability of the fixed version. That is not a security argument. That is a logistics argument, and it happens to be correct.

There is a cost, and the proposer disclosed it rather than burying it: fixes in the easily-discoverable class get less soak time on the development branch before release. Less testing. More regression risk. This is technical debt taken on deliberately and in public, which is the only respectable way to take on technical debt. Structure beats speculation every time — and the structure here is honest about its own load-bearing limits.

The uncomfortable variable: triage discretion

Now the part that should keep node operators awake.

"Easily discoverable" is not a formally specified threshold. The policy describes it by example — a vulnerability an LLM can surface from a simple prompt — and the pull request discussion explicitly acknowledges that classification is not limited to that category. Scope is open. The determination is made by whoever is doing triage, in the moment, without an external reviewer, and with no documented appeals process.

That is a meaningful concentration of unilateral authority written into a formal policy document. It is not sinister. It is also not auditable. And the asymmetry cuts both ways: misclassify a severe bug as easily discoverable and you publish a roadmap for attackers who have not yet upgraded; misclassify a trivially findable bug as hard, and you preserve a year-long silence around something a script kiddie with a chat window could surface in an afternoon.

The thread surfaced a sharper problem that the merged text does not solve. stickies-v pointed out that attackers can monitor the repository quickly and automatically, and argued for disclosure no later than the moment the fix's pull request is submitted. Poinsot's response addressed announcement timing without resolving that specific vector. Which means the fix PR itself remains an intelligence leak with no policy-level mitigation. Anyone watching commit traffic gets a head start on the advisory, embargo or no embargo.

ariard argued for fixing first and announcing after. That was rejected, which is the most consequential decision in the entire thread: it commits the project to simultaneous disclosure, and it strips downstream operators of any buffer window. sedited asked the question that never got a clean answer — whether this needed to be codified at all, or whether flexible convention served better than rigid text. Writing down a norm converts discretion into precedent. Precedent can be cited. Precedent can also calcify.

The governance shape is worth naming plainly. Five named contributors. Substantive disagreement on record. Proposer as the effective adjudicator of competing proposals. Final merge by a single maintainer. Six days end to end. This is high-trust, low-headcount governance, and it is fast precisely because it is small. It is also fragile in a specific way: it has no succession plan for the people doing the triaging, and no independent review layer to catch a bad classification before it becomes a shipped advisory.

The contrarian read: this is labor economics wearing a security costume

Here is where I part company with most of the coverage.

The narrative forming around this change is that AI is eroding the security of crypto infrastructure, and that Bitcoin Core is reacting to a new threat class. That framing is emotionally satisfying and analytically lazy.

Read the trigger again. Poinsot cites a rising volume of reports describing vulnerabilities that are easily — and note the parenthetical — rediscoverable. That word is doing enormous work. It implies duplication. It implies reports arriving that are not novel, not original, and plausibly generated in bulk. The policy is not primarily responding to smarter attackers. It is responding to a triage queue drowning in machine-generated noise, handled by a small number of volunteers and grant-funded researchers who have no commercial incentive to absorb the load.

That reframes the entire document. This is not a security upgrade. It is a workload management decision with security side effects. The embargo was not abandoned because secrecy stopped working in some abstract cryptographic sense — it was abandoned because maintaining secrecy over bugs that are trivially rediscoverable costs more defender hours than it saves. The scarce resource is not information. It is the attention of perhaps a dozen people.

Once you see it that way, the six-day merge stops looking hasty and starts looking like what it is: a bottleneck clearing itself. And once you see it that way, the real risk is not that the policy is wrong. It is that the policy is correct about a problem whose underlying cause — the structural underfunding of defensive labor relative to the collapsing cost of offensive tooling — remains completely unaddressed. AI lowered the cost of finding bugs for everyone. It did not raise the funding available to fix them. That asymmetry is the actual story, and no policy document closes it.

There is a second contrarian point, and it is about who pays. The rewrite externalizes risk downstream. If fixes now ship with same-day advisories, every exchange, custodian, ETF custodian, Lightning implementation, and indexer inherits an implicit service-level obligation: upgrade fast, or wear the exposure. Historically, a meaningful share of node operators do not upgrade fast. The policy improves the theoretical safety of the network while increasing the operational discipline required to realize it. Those are not the same thing, and conflating them is how infrastructure narratives go wrong. Structure beats speculation. It always has — but only for the operators who actually run the structure.

One more blind spot: Bitcoin Core set this policy unilaterally. Bitcoin Knots, btcd, and libbitcoin were not consulted, at least not publicly. If alternative implementations adopt different disclosure calendars, the same vulnerability becomes public on different dates across the ecosystem, creating exactly the information asymmetry that coordinated disclosure exists to prevent. Nobody in the thread addressed this. It deserves a follow-up.

What to watch

The tail event that matters is not this merge. It is the first easily-discoverable vulnerability that gets exploited after its advisory ships — the case that will determine whether fast disclosure is read as competence or as negligence, and whether the policy gets walked back under pressure.

Watch three signals. Whether other clients mirror the tier structure within the next two release cycles. Whether a commercial market for Bitcoin-specific vulnerability intelligence emerges, because institutional custodians cannot run on a public advisory feed alone. And whether the triage function ever gains a second reviewer, which would tell you the project has decided this authority is worth institutionalizing rather than holding informally.

Bitcoin's defense budget is still measured in grant money and goodwill. Its attack budget just got subsidized by every foundation model on the market. That gap does not close with a policy edit — but the policy edit is the first document in years that admits the gap exists. Read it as a confession, not a cure.