Precision metal gears meshing inside a dark machine, with a golden Bitcoin coin serving as the central gear and orange and blue highlights across the metal
AI-generated illustration (FLUX.1-schnell, generated locally) — does not represent real data.

Bitcoin Core 32.0 for Home Node Operators: Upgrade, Wait, or Skip It Entirely

NodeWitness Team 13 min read

Bitcoin Core 32.0 changes no consensus rule, requires no reindex and no wallet migration, and the only thing that actually expires when it ships is support for the 29.x series. What does change for a node at home: 200 default peers instead of 125, parallel input reads during block validation, a rewritten RPC server with a 16-client cap, and a fee estimator that can only ever lower the number the old one gave you.

Update, October 23, 2026: we've added two warnings. The 32.0 GUI writes PSBTs that older Core releases refuse to import, which can stall a multisig where co-signers run different versions; the warning sits right before the checklist. And Bitcoin Core has changed how it discloses vulnerabilities, which is one more reason not to let upgrades slide; that part is at the end, under what happens if you skip this release.

Bitcoin Core's maintainers aimed to tag v32.0 on October 10, 2026 and tagged it on October 21, and the release is the point at which 29.x stops receiving security fixes. That is the entire consequence for an operator who does nothing. Everything else in this release only reaches you if you install it. This piece was written on September 11, 2026, revised on October 13 against rc4, and checked on October 22 against the final release notes [1] that ship with the tag, so every claim carries its date.

Three milestones met, the last one eleven days late

For the consensus-versus-relay-policy distinction that decides whether node software even matters, start with Bitcoin Core vs. Knots, and for each client's defaults read from the source, Core vs. Knots, checked against the code; for how a node behaves through a soft fork, the BIP-110 decision tree; for the wider self-custody picture, managing your Bitcoin.

The schedule lives in issue #35122 [2], opened by maintainer fanquake on April 20, 2026: feature freeze on August 20 (bug fixes only from then on), 32.x branch-off plus v32.0rc1, originally planned for September 10, and the v32.0 tag on October 10, labelled "aim" in the issue itself.

The freeze happened on schedule. Branch-off and v32.0rc1 followed on September 14, four days late, then rc2 on September 18, rc3 on October 1 and rc4 on October 12, with test binaries in the bitcoincore.org download directory. October 10 came and went without a final release, and the v32.0 tag [3] landed on October 21, 2026, signed by sedited at 13:27 UTC. It carries no code change over rc4: the only differences are the version number, the man pages and the release notes. As of October 22, 2026, bitcoincore.org had neither final binaries nor a release page, so there was no official download yet.

Timeline of Bitcoin Core 32.0: feature freeze completed August 20, 2026; 32.x branch and rc1 done on September 14, with rc4 on October 12; final tag aimed for October 10 and signed on October 21; below, maintenance bars showing 30.x and 31.x supported until 33.0 while 29.x loses support when 32.0 ships
Original diagram: the three public milestones and which release series drops out of maintenance at each one. The tag came on October 21, eleven days after the aim; the 33.0 date is an estimate.

More peers, faster block connection

Two changes reach every node, wallet or not. The first is in the final notes: the default peer limit rises from 125 to 200 (PR #28463, merged July 24 under the 32.0 milestone), and a new -inboundrelaypercent option caps transaction-relaying peers at 50% of inbound slots by default. The stated purpose is more inbound capacity for block-relay-only peers; the number of automatic outbound connections is unchanged. With port 8333 open, that is up to 75 more inbound peers plus their file descriptors, memory and bandwidth. -maxconnections still caps it wherever you want, and the notes say -maxconnections=125 -inboundrelaypercent=100 restores the old limits. An explicitly set -maxconnections is left alone, but the new inbound relay cap still applies to it.

The second is in the notes too. Connecting a block means reading, for every spent input, the coin it spends, and those disk reads used to run serially. PR #35295 moves them onto a worker pool that pre-warms the coins cache, controlled by -prevoutfetchthreads (default 8, max 16, 0 disables). The final notes only say it speeds up validation when those coins have to be read from disk, with no multiplier; the win scales with how much of your UTXO set misses dbcache. The "up to 3x faster" figure in some coverage does not appear in the notes.

A rewritten RPC server and a global relay throttle

RPC and REST now run on a from-scratch HTTP server with no libevent dependency (PR #35182). It ships -rpcmaxconnections, default 16 simultaneous clients. If several services share your node's RPC (a mempool explorer, an Electrum server, a Lightning node), that is the first default to inspect. In the other direction, the notes suggest a lower value on resource-constrained machines, since the node now tries to reserve file descriptors for those sockets. A client outside -rpcallowip is now dropped instead of receiving a 403 (#35592), header parsing is stricter, and -debug=libevent warns and is ignored.

Outbound transaction relay is throttled by one global backlog instead of per peer (PR #34628): same 14 tx/s default, a new 12 MB per 10 minutes cap, tunable via -txsendrate, visible in getnetworkinfo. Stated goal: less memory and CPU during volume spikes.

Smaller items in the same vein: automatically created Tor onion services enable Tor's proof-of-work defence when the daemon supports it (#33414); version bits 5–28 no longer trigger unknown-deployment warnings, per BIP 323 (#34779); CJDNS support is under review for removal (#36202); legacy ElGamal I2P sessions are sunset no later than v34 (#35696). There is also a privacy fix for -privatebroadcast=1: when a v2 connection attempt failed, the v1 retry could bypass the forced Tor route and connect directly, exposing the sender's IP (#35410).

Wallet and RPC surface

Fee estimation is the largest behavioural change. estimatesmartfee now runs the classic block-policy estimator alongside a mempool-based one and returns the lower of the two (PR #34075). Mempool data can only pull the recommendation down, never up, because the block-policy estimator is not gameable by stuffing the mempool and the new one might be. The mempool estimator only answers when recent blocks indicate a healthy mempool. When it has nothing to say, for instance right after startup, the call simply returns the block-policy figure, and it errors only when block-policy has no data either, as before. A sparse mempool is a different case: there it falls back to a relayable floor, the higher of the minimum relay fee rate and the current mempool minimum. That is how the final notes and the RPC help describe it; an earlier notes draft warned of an error during warm-up, which no longer applies. estimatesmartfee also takes a fee_rate_estimator option to request block_policy or mempool_policy alone.

Wallet-side: createpsbt, walletcreatefundedpsbt, converttopsbt and psbtbumpfee default to PSBT version 2 (BIP 370), with a psbt_version argument to request v0 for signers that do not speak v2. exportwatchonlywallet exports a private-key-free copy of a descriptor wallet for an online watch node, mirrored by a GUI action; addhdkey adds a BIP 32 extended key to the wallet, and derivehdkey returns an xpub or xprv for a path with at least one hardened step, meant for coordinating multisig. One real security fix: on non-Windows systems, a crafted wallet name could execute arbitrary commands through -walletnotify (#36048). Deprecations proceed (removeprunedfunds, -walletrbf, bip125-replaceable unless -deprecatedrpc=bip125). And the absence worth stating plainly: Silent Payments (BIP 352) is not in 32.0. The base-protocol PR (#35301 [4]) was merged on September 23, after 32.0 branched off, and the sending and receiving PRs are still open as of October 22, whatever some coverage says.

Warning: the 32.0 GUI can stall a mixed-version multisig

The final release notes don't mention this one, but anyone who signs as part of a group should know about it. Build a transaction in the 32.0 GUI and it comes out as a version 2 PSBT, with no setting to change that. Core releases before 32 cannot import v2 and stop with an "unsupported version" decoding error, per the report in issue #36518 [7]; the 31.1 source code agrees, since it only parses version 0. So if one co-signer has upgraded and drafts the spend in the GUI while another is still on 31.x or earlier, the second signature never happens. Nothing is at risk here. The coins stay put; it's the signing round that gets stuck.

fanquake moved the issue to the 32.1 milestone on October 21, noting that 32.0 was overdue and there was nothing ready to backport yet. The proposed fix, PR #36539 [8], switches the GUI back to v0. It was still open when we checked on October 23, as CryptoSlate [9] had also found the day before. Until 32.1 ships, a mixed-version multisig has two ways through: build the PSBT over RPC with psbt_version=0 (both walletcreatefundedpsbt and createpsbt take it), or get every co-signer onto 32.0 first.

Decision checklist, in order

  1. Wait for the final binaries, not the rc. The tag exists, but what you install is the binaries published on bitcoincore.org. Release candidates exist for people hunting bugs. A node that backs funds or services is not a test rig.
  2. Verify before you install. Fetch the binary, SHA256SUMS and its .asc from bitcoincore.org, check the hash, verify the signature against the developer keys published in the repository. No writeup replaces that step.
  3. Shut down, wait for a clean exit, swap binaries. That is the official procedure in full. A large dbcache can make the shutdown take minutes; let it finish.
  4. Port open? Decide your peer cap. Either accept the new 200-peer default and its inbound load, or pin -maxconnections to what the hardware tolerates.
  5. Multiple RPC consumers? Check -rpcmaxconnections. Sixteen concurrent clients is tight for an explorer plus an Electrum server plus Lightning under load.
  6. External signer or older co-signer? Test PSBT v2. A device without v2 support, or a co-signer on Core older than 32, needs psbt_version: 0, or it fails without a useful error. The GUI can't set it.
  7. After restart, confirm height and peers. getblockchaininfo and getnetworkinfo. Same height as the network and peers connected means you are done.

Only step three is mandatory. The rest depend on what is plugged into your node.

What you do not need to do

No funds to move, no seeds to touch: a major release changes neither your keys nor the validity of your transactions. No wallet migration: the final notes mention no format or database migration, and the official upgrade text still says old wallet versions are generally supported. Its only caveat is for upgrades from an end-of-life version, which may take a while if the data directory needs migrating. No reindex: nothing in 32.0 requires -reindex or -reindex-chainstate. The fee-estimates file moves itself to fees/block_policy_estimates.dat on first start.

One item looks mandatory and is not. -txindex shrinks to under half its size, but only if you rebuild it by deleting indexes/txindex and letting the node regenerate it over several hours; the old index keeps working as is. Mind the downgrade path, though: a rebuilt index is unreadable by earlier releases, which rebuild it in the old format; if you downgrade for good, delete indexes/txindex first, since older releases do not reclaim the space used by new-format entries. -txospenderindex also slims down: existing indexes stay compatible with no action needed, and only a rebuild reclaims the space used by data indexed before the upgrade.

If you skip it: what happens and when your version expires

On-chain, nothing. A node on 31.1, 30.3 or 29.4 validates the identical blocks a 32.0 node does, because there is no consensus change here. You keep syncing, relaying and serving your wallet, and no peer disconnects you for the version string you announce.

What expires is maintenance. The project's lifecycle policy [5] keeps the last three major releases and declares the oldest end-of-life when a new one ships, with no security fixes after that, which at a six-to-seven-month cadence works out to roughly 18 months per series according to the table endoflife.date [6] maintains:

Series Latest patch Status once 32.0 is released
31.x 31.1 (July 8, 2026) Maintained until 33.0 ships
30.x 30.3 (July 10, 2026) Maintained until 33.0 ships
29.x 29.4 (July 10, 2026) End of life: no further patches

So a 30.x or 31.x operator can skip this release at zero cost until 33.0 arrives, likely in spring 2027 if the cadence holds, and this same decision comes back. A 29.x operator has a real date: the 32.0 release ends patches for that series, and the final notes commit to disclosing, two weeks later, the medium- and high-severity vulnerabilities fixed in 30.0, three of them. That is the one deadline in this release that does not wait.

Since October 22 there is one more reason not to sit on patches. That day Antoine Poinsot told the Bitcoin development mailing list [10] that Core is updating its disclosure policy, because LLMs have made some classes of bugs, and quiet fixes, far easier to find. A vulnerability triaged as easy to discover, typically something a simple LLM prompt would surface, now gets a point release for every maintained major version as soon as possible, shipped with a security advisory and no embargo. Everything else keeps the severity-based timeline set out in the policy on bitcoincore.org [11]: low severity is disclosed two weeks after the major release that fixes it, medium and high two weeks after the last affected release reaches end of life, and critical bugs get handled case by case. That medium-and-high rule is exactly what puts a date on 29.x.

What it means if you run a node: when a point release lands with an advisory, some of the details are public that same day, so the upgrade is worth doing within days rather than months. And an end-of-life series, as 29.x becomes once 32.0 is out, won't get that point release at all. Cointelegraph [12] has the wider story.

Sources

Labelled by type.

  1. Bitcoin Core, final release notes. (Primary, official repository)
  2. Bitcoin Core, issue #35122. (Primary, official repository)
  3. Bitcoin Core, v32.0 tag. (Primary, official repository)
  4. Bitcoin Core, #35301. (Primary, official repository)
  5. Bitcoin Core, lifecycle policy. (Primary, official project site)
  6. endoflife.date, endoflife.date. (Secondary, aggregator)
  7. Bitcoin Core, issue #36518. (Primary, official repository)
  8. Bitcoin Core, PR #36539. (Primary, official repository)
  9. CryptoSlate, Bitcoin Core 32 can stall multisig signing on older nodes as fix slips to next patch. (Secondary, trade press)
  10. Antoine Poinsot, "Bitcoin Core security policy update", bitcoindev list. (Primary, development mailing list)
  11. Bitcoin Core, security policy and advisories. (Primary, official project site)
  12. Cointelegraph, Bitcoin Core changes security policy as AI makes bugs easier to find. (Secondary, trade press)
  13. NodeWitness, our own data, verifiable on Network and mining. (Primary, own data)

Our node, a full Bitcoin Core without pruning, sat at block 972,584 at 07:34 UTC on October 22, 2026 as this was revised. Its live height and sync status are on Network and mining, so you can check it against the rest of the network whenever you read this rather than trusting a date on a page.

More in Network and mining

See all 15 articles in Network and mining →

Last updated: October 23, 2026