About four in ten reachable Bitcoin Core nodes seen in a network crawl on 18 October run release lines that the project no longer patches, which means the faster security fixes Bitcoin Core adopted on 22 October will not reach them. CryptoSlate, in an article published on 24 October, counted 3,671 of 8,422 self-reported Core peers (43.6%) on end-of-life versions, using a snapshot from the Karlsruhe Institute of Technology (KIT). Coindaro recounted the same KIT file and found a similar share, about 44%.
The figure is an estimate built from one crawl, with version strings that nodes report about themselves. It is not new either: a share of about 43% was already being quoted in May. What has changed is the policy around it. Bitcoin Core will now ship some fixes within days, and only to the three release lines it maintains. A bitcoin node on an older line stays outside that loop.
How the bitcoin node count was made
KIT runs a long-standing Bitcoin network monitor and publishes raw snapshots of the peers it reaches. It does not publish a percentage of outdated nodes. The 43.6% is CryptoSlate’s own computation from the 18 October snapshot file, which lists 9,691 peers reachable over IPv4 and IPv6. CryptoSlate kept the 8,422 that identify as Bitcoin Core and set aside the rest, including nodes running Bitcoin Knots.
The sample has blind spots that the article itself points out. Nodes reachable only over Tor, nodes that do not accept incoming connections, and the private infrastructure of exchanges, custodians and miners do not appear in it. Whatever versions they run, no outside crawler can see them.
CryptoSlate’s breakdown also leaves a small gap. Its four groups (31.x, 30.x, 29.x and 28.x or older) add up to 8,261 peers, not 8,422. The article does not explain the 161 missing peers.
Coindaro downloaded the KIT file and sorted the 9,691 records by user agent. Counting only plain Bitcoin Core strings (of the form /Satoshi:31.1.0/, with no extra label) gave 8,418 Core agents, very close to CryptoSlate’s 8,422. Another 1,096 agents mention Knots (11% of all peers) and 177 belong to other clients or modified builds. Among the 8,418 Core agents, 3,742 were on version 28 or older, 242 of them on the ancient 0.x series. That is 44.5%. Small differences with CryptoSlate’s count come down to classification choices, such as how to treat Knots, release candidates and modified builds.
| Release line | Status on 25 October 2026 | CryptoSlate count (KIT, 18 Oct) | Coindaro recount (same file) |
|---|---|---|---|
| 32.0 release candidates | Not yet released | not given | 37 |
| 31.x | Maintained until 34.0 | 3,243 | 3,278 |
| 30.x | Maintained until 33.0 | 712 | 721 |
| 29.x | Maintained until 32.0 | 635 | 640 |
| 28.x and older | End of life (28.x since 19 April 2026) | 3,671 (43.6%) | 3,742 (44.5%) |
| Base of the share | 8,422 Core peers | 8,418 Core agents, Knots excluded |
Two more caveats apply to both counts. The file is not a single instant: its most recent connection dates from 18 October, but the oldest entries go back to 26 January 2026, so stale peers are mixed in. Keeping only the 5,384 Core agents seen since 1 October, Coindaro still found 43.3% on end-of-life lines. And a node can claim any version string it likes, so the data shows what nodes say they run, not what they run.
A similar share already circulated in May
Readers should not take the 18 October number as a fresh deterioration. On 6 May 2026, the day after Bitcoin Core disclosed the bug CVE-2024-52911, The Block reported that one widely cited estimate, which it tied to Clark Moody’s node dashboard, put about 43% of nodes on software older than version 29. That came from a different tracker with a different method, so the two figures cannot be lined up to draw a trend in either direction.
Other trackers give other pictures again. CryptoTicker, using a btcnodes.io snapshot on 15 September, counted 26,516 nodes and put 60.40% of those with a standard identifier on the 29 series or older, a cut that includes the still-maintained 29.x line. Taken alone, 28.x and older made up 27.09% of that sample. Like KIT, the snapshot leaves out nodes reachable only over Tor. It also showed 4,459 nodes (17.2%) reporting Knots, against 11% in KIT’s file. Trackers that count around 25,000 to 26,000 nodes and KIT’s 9,691 IPv4 and IPv6 peers do not measure the same network, so their percentages should never be mixed.
The fast-fix policy reaches only 31.x, 30.x and 29.x
The new rule, announced by Antoine Poinsot on the bitcoindev mailing list, creates a category for bugs that are easy to find, for instance with a simple prompt to an AI model. For those, the usual months-long wait before disclosure goes away. “For these issues that are easy to find, this is the wrong tradeoff,” Poinsot wrote in his 22 October post. The fix goes out quickly in a point release for each maintained line, with an advisory. The details of the rule are in our 23 October report on the new Bitcoin Core security policy.
“Each maintained line” is the key phrase. The Bitcoin Core lifecycle page says the project always maintains the latest three major versions, today 31.x, 30.x and 29.x, and that end-of-life versions generally do not receive security fixes. Version 28.x reached end of life on 19 April 2026; 27.x did on 10 October 2025.
The supported group is about to shrink again. Version 32.0 was still at the release-candidate stage on 24 October, with no date set. Once it ships, 29.x loses support. On CryptoSlate’s sample, that would put 4,306 peers, or 51.1%, on unsupported lines if nobody upgraded. Coindaro’s recount gives 4,382 of 8,418, or 52.1%. Either way, roughly half.
Bitcoin Core end of life does not mean compromised
A node on an unsupported line still downloads and checks every block under the same consensus rules. The new policy does not touch those rules, and CryptoSlate stressed that its count measures eligibility for fixes, not compromise. No exploitation of any of the disclosed bugs against old nodes is documented in the material Coindaro reviewed. As of 23 October, no advisory had yet been issued under the easy-to-find rule.
The risk is of another kind: crashes and denial of service from bugs that are already public. The clearest case is CVE-2024-52911, a use-after-free in block and script validation disclosed on 5 May 2026. According to the project’s security advisories and The Block, a miner could crash nodes with a specially crafted invalid block, an attack that costs real blockchain and earns a reward, which makes rewriting history very expensive.">proof of work. The project rated it High and judged remote code execution unlikely; The Block added that consensus rules were not affected. The flaw sits in every version from 0.14.0 through 28.x. Cory Fields of MIT’s Digital Currency Initiative reported it privately on 2 November 2024, and the fix shipped in 29.0 in April 2025, 388 days before the public disclosure by CryptoSlate’s count.
A batch disclosed on 24 October 2025, fixed in version 30.0, covered a rare remote crash on 32-bit systems (CVE-2025-46597), a processor-exhaustion attack through unconfirmed transactions (CVE-2025-46598) and two ways to fill a node’s disk (CVE-2025-54604 and CVE-2025-54605). The advisory page does not list which older versions they affect.
There is a structural reason why old lines carry more public bugs, and this is Coindaro’s reading of the policy text rather than a statement from the project. For medium and high severity issues, Bitcoin Core waits until two weeks after the last affected line reaches end of life before publishing details. So by design, the bugs that get disclosed are the ones that are no longer fixed anywhere an old node could receive them. Our guide on where crypto hacks really happen explains why software around the chain, not the chain itself, is the usual weak point.
Why node operators upgrade slowly
Lagging nodes are an old pattern. In a study published in February 2024, developer Jameson Lopp measured, with weekly Bitnodes data, how long it takes for 95% of a release’s peak adoption to move on. That time rose from about one year before July 2018 to about two years. Since 2021, peak adoption has come six to nine months after release. Lopp’s explanation, which he offered as a hypothesis, is the rise of plug-and-play node hardware and software, partly driven by Lightning users, whose owners tend to be less technical and less inclined to update by hand.
Many of those machines were set up once and left alone. For them, a policy that speeds up fixes on maintained lines changes nothing unless the owner, or the vendor of the package, moves the node forward.
How to check your Bitcoin node version
Operators who run Bitcoin Core from the command line can type bitcoin-cli getnetworkinfo. The RPC documentation lists a “subversion” field, the server’s version string (for example /Satoshi:31.0.0/), next to a numeric “version” field. Anything that starts with 28 or lower is on an end-of-life line.
- The lifecycle page recommends the latest maintenance release of the newest major version you can use; today that is the latest 31.x point release.
- As with any software update, download from the official site, bitcoincore.org, and check the signatures on the release files before installing.
- On a node package such as Umbrel or Start9, Bitcoin Core usually updates through the package’s own app store, so that is where to look for the version on offer.
Who needs to move first depends on the bug. In the discussion of the change on GitHub, Poinsot gave the example of a flaw in block template creation, for which miners should update as soon as possible while merchants can take a more careful path. That is one reason the project wants advisories to carry details. One side note for those planning to jump to 32.0 later: CryptoSlate reports that it switches the default PSBT format to version 2, and a user found on 14 October that files from the new graphical wallet failed to import into older Core co-signers, with a fix deferred to 32.1.
Bitcoin Core is not the only node software under pressure to patch faster; the Lightning implementation Eclair shipped a fix that stops web pages from sending commands to Lightning nodes in mid-October. More background on the network is on our Bitcoin page.
What is still unknown
The release date of Bitcoin Core 32.0 has not been set, and with it the day 29.x drops out. No bug has yet been handled under the easy-to-find category, so nobody has seen how fast a point release lands in practice. The 161 peers missing from CryptoSlate’s breakdown are unexplained. And the share of outdated software inside exchanges, custodians and mining pools, which never show up in public crawls, is not known at all.
Two things to watch: the first advisory issued under the easy-to-find rule, and the version mix in KIT’s snapshots once 32.0 is out.