Bitcoin Core 32.0 Arrives October 10: How to Check Whether Your Node Falls Out of Maintenance

The first release candidate for Bitcoin Core 32.0 has been available since September 14, 2026. For you as the operator of your own node that means two things: the feature set of the coming major version is settled, and when it ships the 29 series drops out of the project's maintenance window. Anyone still running 29.x today will get no more security fixes after the planned date of October 10. The check takes two minutes; the update costs half an hour depending on your setup.

Our own count of reachable nodes worldwide, which we carried out for this article on the morning of September 15, shows how large the affected group is: roughly six in ten reachable Bitcoin nodes run a version that will no longer be a maintained one once 32.0 appears. The figures and the method are further down.

Bitcoin Core 32.0: what happened on September 14

Bitcoin Core is the reference software of the Bitcoin network. It checks blocks and transactions against the consensus rules, keeps its own copy of the blockchain and is therefore the foundation for anyone who does not leave their payments to somebody else's infrastructure. By its own schedule, the project publishes a major version roughly every six months.

On September 14, 2026, the tag v32.0rc1 appeared in the project's source repository, the first release candidate of the coming major version. The industry outlet TFTC puts this at 12:58 UTC and gives October 10, 2026 as the planned date for the final tag. That leaves a test window of around four weeks between candidate and release. For comparison: the most recently released major version, 31.0, dates from April 19, 2026 according to the project's lifecycle schedule, and the corresponding maintenance build 31.1 carries the date July 7, 2026 in the download directory.

A release candidate is not a preview in the sense of a beta. The code is considered functionally complete. What still goes in now are fixes for bugs noticed during the test window, and nothing else. For you as an operator that means the content of the coming version is known, and you can check your configuration against it now rather than being surprised on release day.

Release candidate, feature freeze, maintenance window: three terms for this article

Release candidate

A release candidate is a build the project considers ready for publication and puts through broad testing before the final release. It carries the suffix rc1, rc2 and so on, and is withdrawn or replaced if a serious bug turns up.

Feature freeze

A feature freeze is the point from which no new functions are taken into a version. It comes before the first release candidate and is the reason the feature set of 32.0 can already be described.

Maintenance window

The maintenance window is the period in which a major version still receives bug and security fixes. Under its own lifecycle schedule, Bitcoin Core maintains the three most recent major versions at any time. As soon as a new major version appears, the oldest of those three slips out and is considered end of life. Versions in the end-of-life state generally receive no further security fixes either.

Our own analysis: 60 percent of reachable nodes lose maintenance with 32.0

This analysis was carried out by cryptoticker.io on September 15, 2026. The method in one sentence: at 06:35 UTC we retrieved the public snapshot from the node counter btcnodes.io (formerly bitnodes.io) and counted the version identifier each node reports about itself, grouped by major version.

We examined 26,516 nodes from that snapshot. Of those, 25,902 carry an identifier in the usual form with a version number; the remaining 614 report different software, 556 of them a library implementation with no version relation to Bitcoin Core. The count refers to those 25,902 nodes.

• 29.x: 8,629 nodes (33.31 percent) – precisely the series that drops out of maintenance when 32.0 appears.
• 28.x and older: 7,017 nodes (27.09 percent) – already unmaintained today. The 28 series has been end of life since April 19, 2026.
• 30.x: 1,732 nodes (6.69 percent) and 31.x: 8,512 nodes (32.86 percent) – the two series that will continue to be maintained alongside 32.x after the release.
• 32.x: 12 nodes (0.05 percent) – presumably test systems already running the candidate.

Adding the 29 series and everything older gives 15,646 nodes, or 60.40 percent. That majority will be left without maintained software the day after the release. A side finding from the same count: 4,459 nodes (17.2 percent) additionally report the identifier of the divergent implementation Bitcoin Knots, which has its own release rhythm and is untouched by this maintenance schedule.

What this survey cannot do belongs here too. The snapshot contains no country field, so a separate figure for any one country cannot be derived from it. The version identifier is self-reported and technically forgeable. And only nodes reachable from outside are counted. Anyone running their node behind a firewall or reachable exclusively over Tor does not appear in these statistics. The actual number of outdated installations is therefore likely to be higher than shown here.

The Bitcoin Core maintenance window: which version drops out when

The project's lifecycle schedule is a public table and can be read line by line. The entries that matter for you:

• 29.x, released April 14, 2025: end of life when 32.0 appears, so on current plans October 10, 2026.
• 30.x, released October 10, 2025: end of life only with 33.0.
• 31.x, released April 19, 2026: end of life only with 34.0.
• 28.x: end of life since April 19, 2026.

The project explicitly recommends running the most recent maintenance build of the highest major version you can move to. There is one particularity here that argues for a calm upgrade path: the project ships proposals for changes to the consensus rules in maintenance versions first, not in major versions. Anyone updating conservatively therefore still stays compatible, as long as their own major version is maintained. That compatibility is exactly what ends for the 29 series in October.

Reading your Core version: how to find out what your node runs

Before you download anything, establish where you stand. Three routes, depending on your setup.

Command line

On a server or single-board computer, bitcoind --version gives the version number directly in the first line. With the service running it also works via bitcoin-cli --version or, if you are talking to the node anyway, via the call bitcoin-cli getnetworkinfo; there the identifier sits in the subversion field, in the same form our count above used.

Graphical interface

In the desktop application you find the version number under the Help menu item, in the window with the information about the application. It also appears in the debug information window that the application offers under the Window menu item.

Prebuilt node package

Anyone running a turnkey solution, meaning a preconfigured operating system for a home node, usually reads the Core version in the detail view of the respective application. What matters here is the version of Bitcoin Core itself, not the version number of the interface around it. The two figures almost always differ, and only the first decides on maintenance.

Note the number down. If it says 29 or anything lower, you have a task for the coming weeks. If it says 30 or 31, you are on the safe side for now and can plan the update at your leisure.

What changes in Bitcoin Core 32.0: fee estimation, index, interface

The draft release notes for 32.0 sit in the project's development wiki. It is explicitly a draft and may still change before the final tag; the following points should therefore be read as a direction of travel, not as final wording.

What stands out is the emphasis on operation rather than on visible features. Fee estimation will in future combine the block-based estimator with the estimator from the mempool and comes out more cautious as a result. According to the draft, the transaction index takes up less than half the disk space it used to, though only after a rebuild of the index. Block validation gains a parallel prefetch of input data with its own setting for the number of worker threads, preset to eight and capped at sixteen.

At the network layer, the draft has a global rather than a per-connection limit on transaction relay, plus proof protection for Tor services where the counterparty supports it. The outdated encryption of the I2P network is being retired; anyone running their node over it should plan the switch before version 34. The interface gains new calls for handling keys and for exporting a watch-only wallet, and the built-in HTTP server has been rewritten, including a new cap on simultaneous connections.

None of this forces you to act on release day. Two points are still worth noting: the rebuild of the index, if disk space is getting tight, and the removed settings covered in the next section.

Removed options in bitcoin.conf: why your node warns after the update

The most common trouble after a major version jump comes not from the program but from your own configuration file. According to the draft, several settings that stood in guides for years are dropped in 32.0. Among them are a setting for full replaceability of transactions in the mempool and an older network option. Two keys also disappear from the responses of the mempool calls, unless you explicitly switch them back on through the setting for deprecated interfaces.

In practice that means: open your bitcoin.conf before you update and check every line against the release notes. A node that will not start because of an unknown setting, or that comes up with warnings, is an unnecessary night shift. Anyone who has hung their own scripts or accounting software off the interface should additionally check whether one of the disappearing keys is read there.

Testing the release candidate without risking your production node

Four weeks of test window is an invitation, and it applies to operators without a developer background too. The more different setups run the candidate, the sooner bugs surface before they land in the released build. Three rules make testing harmless.

First, a release candidate does not belong on the node your wallet hangs off. A separate device, a virtual machine or a test run on testnet is entirely sufficient. Second, before starting you verify the signature of the downloaded files against the published checksums; that is as mandatory for a pre-release build as for a regular release. Third, you report anything odd while the window is still open. After the final tag, the route for fixes is considerably longer.

Anyone wanting to be sure makes a backup of the wallet file and the configuration file before every version jump and keeps it separate from the node. That applies to the candidate as much as to the later release. How strictly the same discipline applies to hardware devices was demonstrated this year by the case of a manufacturer whose firmware bug affected an entire device generation.

No node of your own? What this update says about your custody

The larger part of the readership runs no node of their own, and that is a legitimate decision. This release still has something to say to you. Anyone leaving their holdings at an exchange or a broker is relying on somebody there keeping an eye on this maintenance window. Anyone self-custodying but reaching a third-party server through a wallet application is relying on the same unknown third party, just one layer down.

The practical middle route for most people is separating keys from software: the keys sit on a device that never touches the network, the software stays replaceable. Which devices are suitable and how they differ is in our hardware wallet comparison. Your own node comes as a second step after that, and the version question from this article becomes yours from then on.

Two cases from recent weeks show that maintenance is no marginal topic: a vulnerability in a Lightning implementation and a critical hole in a widely used wallet interface where only reachability from the internet decided the risk. In both cases the remedy was an update that was already available.

What this release is not: no consensus change and no price event

A word against the obvious wrong conclusions. On the draft as it stands, Bitcoin Core 32.0 changes no consensus rules. There is no vote, no signalling deadline and no point at which a node that has not updated falls out of the network. A node on version 29 will keep validating correctly after October 10. What it lacks are fixes for bugs found after that.

Nor is a release a price event. Anyone drawing a connection between version numbers and price moves is claiming something that cannot be demonstrated. The relevance of this date lies purely in operations: in the question of whether the software checking your payments is still maintained.

That leaves the question of timing. A jump to 32.0 on release day is no mistake for a private node, but no obligation either. Anyone on 30.x or 31.x has months. Anyone on 29.x or below should plan the switch for October, and specifically to the most recent maintenance build of the highest major version their setup allows. For setups where a full node demands too much disk space, pruned mode remains an option; the node does the validation work unchanged either way.

Checking Bitcoin Core 32: what to take away

1. Read your version and note it down. Via bitcoind --version, via the information window of the desktop application, or in the detail view of your turnkey solution. If it says 29 or less, put a date in October in your calendar. Anyone not yet self-custodying should settle the key question first and look at the hardware wallet comparison for that.
2. Prepare your configuration file and a backup. Check every line of your bitcoin.conf against the release notes, and back up the wallet file and the configuration separately. Anyone keeping their keys in an application on their computer should check its update situation in parallel through our software wallet comparison.
3. Test on a separate device, then move over calmly. Never run the candidate on the node your wallet hangs off. And if you conclude that you do not want to run a node of your own at all, then choosing the custodian is the decision that counts at this point, and the exchange comparison is worth a look for that.

The sources for this article: the Bitcoin Core lifecycle schedule with the maintenance table and the tag list of the source repository, where the candidate v32.0rc1 appears with its date.

(As of September 15, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)