On 23 October the crypto press reported that Bitcoin Core had rewritten its security policy for a world where an LLM finds bugs in one prompt, and that the project was abandoning long embargoes for flaws an attacker could trivially rediscover. That is a real change and it is worth reporting. It is also seven days older than the coverage, and it is a good deal smaller than “abandoning”.
I pulled the commit. The diff that changed the policy is ten lines added and one line deleted, and the deleted line was immediately re-added with a single word inserted into it. The entire severity-dependent embargo schedule, the part that actually governs how long you are not told, survived the rewrite verbatim. Nothing was abandoned. A carve-out was added beside it.
Which leaves the question the coverage skipped. If the embargoes are still there, how long are they? Bitcoin Core publishes the answer. Every security advisory it has ever issued carries a dated timeline listing when the bug was reported, when the fix was merged into public master, when it shipped, and when anyone was finally told. Twenty-two of them. Nobody has ever added up the gap.
I added it up. The median distance between a fix landing in public, readable source and the advisory describing what it fixed is 1,167 days. Three years and two months. The longest is 3,407 days. That is the hundred and fifth unasked half of fairness.
TL;DR
- Bitcoin Core’s security policy changed on 16 October 2026, commit
3e2cd6affc, a diff of +10 / -1. The press wrote it up on 23 October. - The one deleted line was re-added with the word “embargoed” inserted. The embargo schedule itself is unchanged. The new rule is a carve-out for bugs classed as “easily discoverable”, not a replacement.
- Across all 22 published advisories, the median gap between the fix entering public master and the advisory is 1,167 days (3.20 years); the maximum is 3,407 days (9.33 years). 17 of 22 exceeded a year.
- Excluding the one-day backlog dump of 10 advisories in July 2024, the median is still 518 days, with 7 of the remaining 12 over a year.
- This is policy working, not failing: the Low-severity rule was honoured to the day, 14 days exactly, five times. The delay is deliberate.
- Two advisories say the fix was pushed covertly. One sat in an open, public pull request for 545 days before anyone was told what it was.
What actually changed on 16 October
The policy lives in one file in the bitcoin-core/bitcoincore.org repository, rendered at the project’s Security Advisories page. Its commit history has twelve entries. The most recent is dated 16 October 2026, titled “Update security policy for easy-to-find vulnerabilities”, authored that day and committed on 22 October.
Here is the whole of what was added:
The public disclosure timeline will depend on whether we classify a reported vulnerability as easily discoverable. This classification applies to vulnerabilities that can be discovered with minimal effort, such as through a simple LLM prompt.
For easily discoverable vulnerabilities, we will publish a point release containing the fix for each maintained major version as soon as possible, along with a security advisory, without applying the standard severity-dependent embargo periods. Otherwise, disclosure follows the severity-dependent timelines detailed below.
And here is the only deletion in the entire commit, shown against its replacement:
Removed: “A pre-announcement will be made two weeks prior to releasing the details of a vulnerability.”
Added: “A pre-announcement will be made two weeks prior to releasing the details of an embargoed vulnerability.”
One word. That is the sum total of what was taken out of Bitcoin Core’s disclosure policy. The schedule that follows it is untouched and still reads, today, exactly as it did before:
Low severity vulnerabilities will be disclosed 2 weeks after the release of a major version containing the fix. Medium and High severity vulnerabilities will be disclosed 2 weeks after the last affected release goes End of Life (approximately a year after a major version containing the fix was first released).
So the embargo was not abandoned. A new class was defined that sits outside it, and everything that does not fall into that class is governed by the same timetable as last month. “Otherwise, disclosure follows the severity-dependent timelines detailed below” is the load-bearing sentence in the change, and it is the one sentence the coverage did not quote.
What the commit message says that the policy page does not
The published policy is clinical. The commit message that carried it is not, and it is a far better document. It is also not reproduced anywhere on the website, which means the clearest statement of why this happened is visible only to people who read the repository.
It opens by giving the cause plainly: “We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered. This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes.”
Then it concedes the cost of the old approach in terms no press release would use. “Because of the nature of our project, coupled with a slow upgrade culture, our security policy favours a longer embargo period. This generally means security fixes can’t be backported, and only become available with users along with the next major release.” And finally: “For these issues that are easy to find, this is the wrong tradeoff. The embargo period achieves little but it delays the availability of a fixed release.”
That is a maintainer writing down, without being asked, that the embargo has been costing users working fixes. It is an honest document. It is also the reason the measurement below is worth taking: the project itself has just said the delay has a price, and the archive is where the delay is recorded.
The archive nobody clocked
Bitcoin Core has published 22 security advisories, all of them since July 2024, across seven publication dates. Each one is a markdown file in the same public repository, and each ends with a section headed “Timeline” giving dated entries: when the bug was privately reported, when a pull request fixing it was opened, when that pull request was merged into master, when a release shipped carrying it, when the last vulnerable version reached end of life, and when the public was finally told.
That structure is unusual and it is to the project’s credit. It also makes the embargo measurable, because the merge date is the moment the fix became public source code that anyone could read, and the disclosure date is the moment anyone was told what it meant. The interval between the two is the window in which the defect was fixed in the open and described nowhere.
1,167 days
Taking all 22 advisories and the merge-to-advisory gap in each:
| Measure | Days | Years |
|---|---|---|
| Minimum | 77 | 0.21 |
| Median | 1,167 | 3.20 |
| Mean | 1,174 | 3.21 |
| Maximum | 3,407 | 9.33 |
Seventeen of the twenty-two sat longer than a year. Thirteen sat longer than two years. Seven sat longer than four. Broken out by the project’s own severity classes:
| Severity | Count | Median gap | Longest |
|---|---|---|---|
| High | 6 | 929 days (2.54y) | 1,920 days |
| Medium | 9 | 1,511 days (4.14y) | 3,407 days |
| Low | 7 | 120 days (0.33y) | 1,513 days |
Medium outlasting High is not an error. It is the backlog, and it is the first thing a fair reading has to account for.
The fixing is fast, the telling is slow
One number cuts against the easy criticism and it belongs here. Measured from the private report to the fix landing in master, Bitcoin Core’s median response is 30 days. Twelve of the twenty-two were fixed inside 60 days. The fastest, CVE-2024-52921, was raised in the project’s development IRC channel on 8 May 2023 and merged on 10 May, two days later.
There are slow ones, and the timelines explain why. CVE-2019-25220 took 1,310 days from report to merge, because, by the advisory’s own account, the attack only became cheap enough to warrant immediate action years after it was first raised. But the central tendency is unambiguous. This is a project that fixes security bugs in about a month and then waits about three years to describe them. The delay is not in the engineering. It is entirely in the telling, and that is the only reason it can be called an embargo at all.
The control that keeps this honest
Ten of the twenty-two advisories were published on a single day, 3 July 2024, covering bugs reported between 2015 and 2020. That was not an embargo running its course. That was a project that had never published advisories starting to publish them, and clearing a decade of history in one go. Counting those ten as “embargoes” and quoting the resulting median as though it described current practice would be dishonest.
So, excluding that batch entirely:
| Group | n | Median gap | Range |
|---|---|---|---|
| July 2024 backlog dump | 10 | 1,612 days (4.41y) | 1,358 to 3,407 |
| Everything else | 12 | 518 days (1.42y) | 77 to 1,226 |
The finding survives the control. Outside the historical catch-up, the median fix still spent 518 days as public code before anyone explained it, and 7 of those 12 ran over a year. The headline number is 1,167; the number that describes ordinary practice is 518. Both are in this post because quoting only the larger one would be the same trick I am complaining about.
This is the policy working
The important and slightly awkward finding is that Bitcoin Core follows its own timetable with real precision. The policy says Low severity is disclosed two weeks after the major release carrying the fix. Checked against every Low-severity advisory issued under the current policy:
| Advisory | Release | Disclosure | Gap |
|---|---|---|---|
| CVE-2024-52919 (part 2) | 2025-04-14, v29.0 | 2025-04-28 | 14 days |
| CVE-2025-46597 | 2025-10-10, v30.0 | 2025-10-24 | 14 days |
| CVE-2025-46598 | 2025-10-10, v30.0 | 2025-10-24 | 14 days |
| CVE-2025-54604 | 2025-10-10, v30.0 | 2025-10-24 | 14 days |
| CVE-2025-54605 | 2025-10-10, v30.0 | 2025-10-24 | 14 days |
Fourteen days, five times, to the day. And the sole High-severity advisory issued under the end-of-life rule, CVE-2024-52911, was disclosed 16 days after the last vulnerable release went end of life, which itself fell 372 days after the fixed version shipped. The policy predicted “approximately a year”. It got 372 days.
That matters because it rules out the lazy reading. These gaps are not neglect, drift, or a backlog nobody got to. They are the schedule, executed accurately. Bitcoin Core is telling you in advance that a Medium or High severity flaw will stay undescribed until roughly a year after the fix ships, and then it does exactly that. The delay is the design.
The covert fix, in the project’s own words
The commit message said LLMs can now “identify covert fixes”. That phrase is not abstract. It is the archive’s own vocabulary, and two advisories use it.
CVE-2025-46597 records that “Antoine Poinsot proposed and implemented a covert mitigation“, and its timeline notes a pull request opened “with a covert fix”. CVE-2024-52911, a High-severity use-after-free in the script interpreter that the advisory concedes “could have been used for remote code execution”, has this entry: “2024-11-06 Pieter Wuille pushes a covert fix to already open PR #31112 which works around the issue by removing the early returns.”
Pushed to an already open pull request. In public. On 6 November 2024. The advisory explaining what that code was for appeared on 5 May 2026, 545 days later. For eighteen months, the patch for a remotely triggerable memory-corruption bug in Bitcoin Core was sitting in a public repository, reviewable by anyone, labelled as a refactor.
The practice is older than the policy. The 2019 timeline for CVE-2024-52914 records the reporter’s assessment of the proposed patch, quoted in the advisory: the fix “seems solid and [..] doesn’t attract attention“. And the timeline for CVE-2019-25220 states that in February 2022 two maintainers agreed the attack had become cheap enough that it “warrants immediate action, and the need to avoid talking about it publicly“.
None of that is misconduct. Patching before publishing is correct, and anyone arguing otherwise is arguing that the attacker deserves a head start. But “doesn’t attract attention” is a security property, and it is precisely the property a language model reading every merged diff in a public repository removes. That is what the 16 October commit is responding to, and the project said so itself.
Three times the secret was already out
The archive also records, against itself, how often the embargo was protecting information that had already escaped.
CVE-2020-14198: the reporter “publicly discloses the vulnerability on the original PR which introduced the quadratic behaviour” on 8 June 2020, the same day it was privately reported. The official advisory followed on 3 July 2024, 1,486 days after the bug was described in public by the person who found it.
CVE-2024-52914: “The issue is partially disclosed during a PR review club” on 22 July 2020, with the advisory linking the transcript. Public advisory 3 July 2024, 1,442 days later.
CVE-2015-3641: a disclosure was pre-announced on the bitcoin-dev mailing list on 25 June 2015, then formally “postponed” on 7 July 2015. It was finally published on 3 July 2024, 3,296 days after the project told the world it was about to explain it.
In each case the embargo continued to run after the information it protected was already public, because the schedule is keyed to release and end-of-life dates, not to whether the secret still exists.
The archive disagrees with itself
One thing I checked because the series requires checking it. The most recent advisory, CVE-2024-52911 from May 2026, dates the release that fixed it: “2025-04-12 Bitcoin Core version 29.0 is released with a fix.”
The advisory for CVE-2024-52919 part 2 says “2025-04-14 – Bitcoin Core v29.0 is released with the 64-bit identifier”, and its summary repeats “April 14th 2025”. The project’s own release announcement is published at a URL containing /2025/04/14/release-29.0/.
So the newest file in the archive misdates, by two days, the release of the version that fixed the bug it is describing. It changes nothing in the figures above, which key off merge dates. It is in this post because a post built on someone else’s dated records should say when those records contradict each other.
Four posts this is not
This series has been near this ground before and the distinction is the whole point.
The thirty-ninth instalment argued that responsible disclosure, done correctly, still creates an interval in which everyone downstream verified honestly and incompletely. It closed on a specific admission: “Nobody has ever put a price on that interval, and it is the thirty-ninth unasked half of fairness.” It contained no figure, no median, and no measurement of any kind. This post is that price. The interval has a number now, and the number is 1,167 days, or 518 outside the backlog.
The twenty-fifth is about uptake: a fix that is published and explained still protects only the people who install it. That is the window after disclosure. This is the window before it.
The thirty-sixth is about validity against carriage, a transaction that was consensus-legal and that no ordinary node would relay. Different axis entirely.
And the liveness post covers what happens when randomness never arrives, which is a failure you can see. Everything here is a failure you cannot.
What this means for a draw
Be careful with the inference, because the obvious one is wrong. None of these are randomness bugs. They are crashes, memory exhaustion, disk filling and propagation delays, and no amount of any of that bends a verifiable random function. A Chainlink VRF proof is checked against a published key hash; a bent proof fails the check. A node that crashes does not produce a dishonest draw, it produces no draw.
So the claim is not “your game was rigged”. The claim is narrower and harder to dismiss: for a median of 1,167 days, the software you were verifying through carried a defect its maintainers had already fixed and had decided not to describe yet. Your verification was correct. It was also running on ground that was under a question you were not allowed to ask, and now we know how long you were not allowed to ask it.
Satoshie does not escape this and I am not going to pretend it does. Satoshie runs on Base, which is client software with its own upgrade schedule, its own maintainers, and its own perfectly reasonable practice of fixing things before announcing them. The Chainlink VRF coordinator that settles a draw is a smart contract maintained by people who are also entitled to patch quietly. Anyone selling you an on-chain game as immune to this is selling you something.
What is genuinely different is the shape of the two questions. Whether your draw was fair is a closed question: the proof is published with the outcome, you can check it today, and you could check it again in four years and get the same answer. Whether the substrate was sound is a retrospective question, one that somebody else closes on your behalf, later, at their discretion, in a markdown file. Bitcoin Core publishes that file, with dates, which is why this post could be written at all. A closed-source casino’s patch history has no such file. Its window never opens because it was never acknowledged, and that is silence, not safety.
The honest summary of provable fairness is that it settles the draw completely and has never settled the ground the draw stood on. The difference worth paying for is that in the open stack, the ground’s history eventually gets written down, and somebody can count it.
Honest limits
- Twenty-two is a small sample, and ten of them were published on one day as a historical clear-out. Every figure here is reported with and without that batch for exactly that reason.
- “Merged into master” is my choice of start point, not the project’s. It is the moment the fix became publicly readable, which is what I am measuring, but someone arguing the embargo properly starts at the release date would get 1,052 days median instead of 1,167.
- The archive is only what has been published. Bugs fixed quietly and never written up do not appear, so these numbers are a floor on the practice, not a census of it.
- Three advisories are dated 8 October 2024 in their filenames but say 9 October in their own timelines. I used the timeline dates. The discrepancy is one day and changes nothing.
- I did not verify the merge dates against the pull requests themselves. Every date here is the project’s own record of its own history, which is the right source for “what did you tell people”, but it is not independent of the project.
- The press framing I am correcting may be the outlet’s compression, not the reporter’s misreading. The underlying coverage got the substance right; it was the word “abandoning” and the absent “otherwise” clause that prompted this.
Three questions
- Now that “easily discoverable” is a classification applied at triage, how many of the 22 past advisories would have qualified, and will the project say?
- If an LLM can identify covert fixes in a public repository, is the merge date still a meaningful embargo boundary for anybody, or only for people not running one?
- Does any chain your games settle on publish a dated disclosure archive at all, and if not, what exactly is the basis for believing its window is shorter?
Run it yourself
Nothing here needs special access. The policy file and its full commit history are at bitcoin-core/bitcoincore.org under _posts/en/pages/2024-06-26-security-advisories.md; the 16 October change is commit 3e2cd6affc and the GitHub commits API returns its diff as +10 / -1. The 22 advisories are markdown files under _posts/en/posts/ with “disclose” in the filename, each carrying its severity as a bolded word and its dates in a Timeline section. Fetch them raw, parse the timelines, subtract the merge date from the disclosure date, and take the median.
One warning from doing it: the file listing has no trailing newline, so a shell loop reading it line by line silently drops the last entry, which is the only advisory published in 2026 and the one carrying the 545-day covert fix. Count what you downloaded before you compute anything with it.
📷 Photo by Immo Wegmann (@tinkerman) on Unsplash
