Bitcoin Core merged a policy amendment on Oct. 22 that lets developers backport fixes for easily rediscovered vulnerabilities to every maintained release line and publish an advisory alongside them.
A network snapshot from Oct. 18 shows that 3,671 of 8,422 self-reported Bitcoin Core peers (43.6%) ran release lines that had already reached end of life.
The count comes from connected public peers in the Karlsruhe Institute of Technology’s Bitcoin network monitor and reflects maintenance eligibility.
A node on an unsupported version can keep validating blocks correctly, and the figure doesn’t measure compromise.
What changed for Bitcoin on Oct. 22
Under the old policy, medium- and high-severity vulnerabilities stayed under embargo until two weeks past the end of life of the last affected release.
That can mean about a year between a fix and the publication of its details. Long embargoes also discouraged openly backporting a fix, since the backport itself could reveal the flaw.
Antoine Poinsot argued in the Oct. 22 announcement that the arrangement fits badly with bugs that AI systems can rediscover:
“The embargo period achieves little but it delays the availability of a fixed release.”
Developers can now mark a flaw as easily discoverable during triage, a test based on how readily it can be found or rediscovered, including by large language models.
Those fixes go to all maintained major lines through point releases, with an advisory published alongside, and other vulnerabilities follow the standard severity schedule. Poinsot acknowledged a cost in an Oct. 20 discussion, noting that “mitigations won’t have as much ‘bake time’ in development branches.”
The new category awaits its first publicly identified use as of Oct. 23. AI-assisted campaigns such as Bitcoin Red Team’s are producing large piles of candidate findings.
The support cliff
Bitcoin Core maintains its three newest major lines, currently 29.x, 30.x and 31.x. The snapshot found 3,243 peers on 31.x, 712 on 30.x and 635 on 29.x, with the 3,671 peers on 28.x and older already unsupported.
Once version 32.0 is formally released, 29.x leaves the maintenance window. If the sample stayed unchanged, 4,306 of 8,422 peers, or 51.1%, would sit on unsupported lines.
The measurement covers 8,422 Bitcoin Core peers among 9,691 connected IPv4 and IPv6 peers, so Tor-only and non-listening nodes fall outside it, along with infrastructure run privately by exchanges, custodians and miners.
Software versions are self-reported, and Bitcoin Knots and other implementations are counted separately.
An earlier CryptoTicker estimate of 60.4% included 4,459 Knots nodes, which follow a different maintenance schedule, so it describes a different population. A node on a maintained major version can also miss a fix if its operator skips the newest point release.
Why Bitcoin operators may wait
Upgrades are voluntary, and each one is operational work. Core 32 switches the default format of partially signed Bitcoin transactions from version 0 to version 2.
A user reported on Oct. 14 that files generated by the new graphical wallet failed to import in older Core co-signers in a multisignature setup. A fix was deferred toward 32.1, and RPC users can request the older format.
An organization coordinating signers, wallet software, and controls has a reason to test before upgrading.
CVE-2024-52911, a high-severity use-after-free in block validation, affected versions later than 0.14.0 and earlier than 29.0, and a crafted invalid block could crash a node.
Exploitation required mining a block with sufficient proof of work, which makes it far costlier than an inexpensive network-message attack. Developers received the report in November 2024, fixed it in 29.0 in April 2025, and disclosed it on May 5, 2026, about 388 days later, once the last affected maintained release reached end of life.
Core 32.0’s release notes say three medium- or high-severity vulnerabilities fixed in version 30.0 will be disclosed two weeks past the new release.
Version 30.0 shipped in October 2025, so the planned disclosures illustrate the old embargo model. As of Oct. 24, the download directory still listed release candidates, while the lifecycle page listed the 32.0 release date as TBA.
Bitcoin Core’s severity policy reserves “critical” for failures such as unauthorized issuance or a permanent chain split, and the new policy alters security coordination and leaves consensus rules as written.
The next test is operator adoption
Faster patches protect nodes only after operators install them. Tracking the same monitor after Core 32.0 ships, with changes in the sample separated from upgrades, will show whether operators move onto maintained versions.
AI,Featured,Governance,Technology#Bitcoin #Core #speeds #security #fixes #surveyed #nodes #run #unsupported #versions1792854528
