The pull request opened on October 16. It merged on October 22. Six days. Five named participants. No external security review, no committee, no vote.
Inside that window, Bitcoin Core โ the reference client the entire bitcoin economy leans on without ever saying so โ rewrote the rules for when the world learns about its worst bugs.
No consensus change. The src/ directory is untouched. No soft fork, no hard fork, no script semantics, no block size. What moved was a document.
And a document controls only one thing: a time function. When a patch ships. When an advisory drops. How many hours an attacker holds information before a defender does.
That time function is worth more than most people in this market realize. A vulnerability nobody can patch is a liability. A vulnerability somebody can patch but nobody knows about is a choice.
Here is the machinery as it stood.
Bitcoin Core runs a coordinated vulnerability disclosure process. A researcher reports privately. Maintainers triage. A fix is developed under embargo. Then a patch release and a security advisory land together. Embargo length scaled with severity:
โ Low: two weeks after the fixed release ships. โ Medium and high: two weeks after the last affected version reaches end of life. In practice, roughly a year after the fix first shipped. โ Critical: handled case by case.
Read that middle row again. A year. In an ecosystem where major releases land on a roughly six-month cadence.
The October revision inserts a fourth row above everything else: "easily discoverable." When a triaged bug lands in this class, the patch ships immediately and the advisory publishes at the same moment. Standard embargo does not apply.
Antoine Poinsot, a Chaincode Labsโfunded contributor with a long public record in Miniscript and hardware signing, made the argument plainly: on these reports the embargo "barely did anything, just delayed the availability of the fixed version." fanquake merged it.
Now the part I would flag in an audit, and the part almost nobody will read.
The real technical finding is not "publish faster." It is backports.
Under the old schedule a high-severity fix sat under embargo for roughly a year. During that year maintainers could not publish a backport to older major versions, because the binary is the leak โ shipping a patch to version N-2 tells the world precisely where to look in version N-2. So operators on older versions received nothing. No patch, no notice, no timeline. They waited for the next major release and only then learned why.
Compressing the embargo is not primarily a disclosure decision. It is what makes backporting possible at all. That is the actual security gain, and it sits downstream of the headline. Poinsot's framing undersells his own change.
The cost is stated openly, and credit where due: fixes now get less soak time on the development branch. He says so directly. That is disclosed technical debt, not hidden debt โ a rarity worth naming.
I spent six weeks in 2019 decompiling MakerDAO's legacy CDP contracts and found a race condition in the price-feed path that let undercollateralized loans through during volatility. The lesson I carried out of that fork was not about oracles. It was that the danger always hides in the seam between two timing assumptions that were each individually reasonable. This policy is a seam. Release cadence is one assumption. Embargo length is the other. For years they were quietly incompatible, and nobody had written it down.
Then there is the discretionary gate.
Someone decides what counts as "easily discoverable." The policy offers illustrative examples, not a definition. And the PR description concedes the classification "is not limited to this category" โ the bucket is open-ended by design.
So: an unenumerated standard, applied by a reviewer with no published reclassification path, inside a process with no external appeal. Trust is math, not magic โ and there is no math here, only judgment.
The ghost in the audit is never the code you read. It is the branch that wasn't there. Same shape here. The document specifies what happens after classification and says nothing about reviewing the classification. If a critical bug is misjudged as easily discoverable, its advisory ships beside the patch and every operator with a lagging upgrade cycle receives a roadmap. If a genuinely trivial bug is misjudged the other way, it disappears into a year-long embargo that no longer serves anyone.
There is a second leak surface, raised in the thread and not closed. stickies-v noted that attackers can monitor the repository "quickly and automatically," and argued disclosure should happen at latest when the fix pull request is submitted. The response addressed announcement timing. It did not address the commit.
Which leaves the meaningful vector untouched: when the vault opens itself, the first thing to walk out is the diff. A one-line commit titled fix: bounds check is a stronger signal than any advisory, and it is public the instant it is pushed. Nothing in this document changes that.
The dissent is worth recording, because the record is the only audit this process has. ariard argued for fixing first and announcing later. Rejected. sedited asked whether this needed to be codified at all, or whether informal convention was doing the job. Partially addressed, not closed. Both objections were substantive, both were answered by the same person who authored the proposal, and both were resolved in six days.
Now the reading everyone will adopt: "Bitcoin Core is AI-proofing its disclosure process."
I don't buy it. Read the stimulus, not the response. Poinsot cites a rise in reports of "easily (re-)discoverable" vulnerabilities. That parenthetical is doing heavy lifting. A rise in re-discovery is not a rise in vulnerability quality โ it is a rise in duplicate, non-original, machine-generated submissions. My Compound cToken work taught me the same lesson from the other side: an exploitable rounding error cost me two weeks of real study. A plausible-sounding report costs a language model ninety seconds.
So this is not a threat-model update. It is triage load relief wearing a threat-model update's clothes. That is a legitimate thing to want โ volunteer maintainers have always been the scarcest resource in this ecosystem โ but it changes what to watch. The failure mode is not that attackers read advisories faster. It is that a tired reviewer, drowning in synthetic reports, starts classifying by pattern-match.
There is also a downstream assumption nobody has priced. Bitcoin Core maintains several major versions at once. Each security fix now implies multiple backports, multiple signed binaries, multiple advisories, compressed into a shorter window. Six days to adopt a policy. Six months of that policy to discover whether the maintainer bandwidth was ever there.
Where this goes: within a year, expect the first public dispute over a disputed classification โ a bug shipped with an instant advisory that some downstream operator insists was never easy to find. Second, watch adoption. If Bitcoin Knots or btcd do not mirror the rhythm, a disclosure gap becomes an arbitrage surface, and disagreements will be about information asymmetry rather than code. Third, the durable artifact is commercial: exchange and custodian node teams are about to learn they need paid vulnerability intelligence, because a six-month upgrade cadence against an instant-advisory regime is a bet they will lose slowly and then quickly.
The policy got shorter.
Silence speaks louder than the proof โ and now it expires faster.