Bitcoin Core 32.1 Released on October 27, 2026: Why 32.0 Was Pulled, the Three Disclosed Bugs and the New Fee Estimator

1. What is Bitcoin Core 32.1, and why is there no 32.0?

Bitcoin Core is the reference implementation of Bitcoin, the software that validates blocks, relays transactions and runs the wallet behind many services. It ships one major version roughly every six months and maintains the three newest. Version 32.1, published on October 27, 2026, is the first public release of the 32.x line, with a new fee estimator, higher connection defaults, a smaller transaction index, PSBT version 2 as the default in the wallet RPCs and a batch of security fixes. It changes no consensus rule: blocks and transactions valid before are valid after.

32.0 exists only as a tag. Maintainer fanquake tagged it on October 21 and wrote in the release schedule issue on October 26 that, due to last-minute issues, 32.0 would not be announced or released and no binaries would be uploaded; 32.1 would follow with the same content plus additional fixes. The pull request that finalised 32.1, merged that afternoon, backports exactly three changes by Antoine Poinsot: socket exception monitoring aligned between the poll and select backends, a 20-minute timeout for peers whose send buffer never drains, and 64-bit positions in the block and undo files. Those are the fixes for the three vulnerabilities disclosed two days later, described in section 3. The project has not said more about the reasons than that.

2. When was it released? Key dates

Dates come from the Bitcoin Core release schedule issue, the bitcoincore.org download server and the disclosure posts. Status as of November 1, 2026.

3. Which vulnerabilities were fixed and disclosed?

Three, all published on October 28, 2026 and all found by the same route: an automated scan of the code by a large language model, run as Project Loupe by Elias Rohrer at Spiral, with Gregory Sanders validating each finding and reporting it to the Bitcoin Core security team. Two were independently rediscovered by other researchers before the fixes shipped. Bitcoin Core's policy is to disclose bugs it rates as easily discoverable as soon as fixed releases exist for every maintained branch, which is why the write-ups came one day after 32.1.

CVE-2026-117349, rated medium: a peer that claims not to support BIP 31 pings is never disconnected for ignoring them, and if it also reads messages very slowly the node keeps queuing transaction announcements for it without limit. The post puts the growth at up to about 2 MB per hour for an inbound peer and 5 MB per hour for an outbound one; nodes running with blocksonly are far less exposed. Reported on September 15, fixed by pull request #36667, which disconnects a paused peer that has not drained its send buffer within 20 minutes.

CVE-2026-117350, rated medium, affects Windows, macOS and BSD only: the select-based socket code checked for exceptional conditions even while reads were paused for backpressure, so a peer sending TCP urgent data could force reads that bypass the per-peer memory limit until the node runs out of memory. Linux uses poll and is not affected. Reported on October 23, three days before the fixes were merged, and fixed by pull request #36665.

CVE-2026-117346, rated low: block and undo file positions were 32-bit, so once an undo file passed 4 GiB newer data overwrote older data, and a later reorg that needed that data would shut the node down until a reindex on a fixed version. On Windows and 32-bit systems writes fail past 2 GiB. The post calls exploitation on 64-bit systems impractical: a miner would need several thousand blocks of nonstandard transactions, about a month of blocks, placed precisely, plus a specific two-block reorg. First reported on July 8, fixed by pull request #36669, which stores positions as 64-bit integers without changing the on-disk format; 32-bit systems remain affected.

32.1's own release notes list further fixes that are not CVEs: a private-broadcast retry that could leak the sender's IP by bypassing the Tor proxy, a command execution path through crafted wallet names with walletnotify on non-Windows systems, and caps of 10,000 queued private-broadcast transactions and 1,000 send attempts each. The notes also say that in two weeks the project will disclose three medium and high severity vulnerabilities fixed in 30.0 (and none of low severity in 32.1), so another disclosure post is due around November 10.

4. How does the new fee estimator change the fees you pay?

If you use a wallet or service that asks a Bitcoin Core node for a fee through estimatesmartfee, 32.1 changes what it hears. Until now Core only used its block policy estimator, which looks back at the fee rates of transactions that got confirmed within a target number of blocks. It is conservative and slow to come down: after a congestion spike it keeps proposing high rates for a while because the history still says high. 32.1 adds a mempool policy estimator that looks at what is waiting right now, and estimatesmartfee returns the lower of the two. The mempool estimator can only lower the result, never raise it, so a Core-based wallet stops overpaying sooner once blocks clear, and behaves as before when the mempool is full.

The same idea drives the rates most explorers show. On November 1, 2026 mempool.space, which estimates from the mempool alone, puts the half-hour target at 1 sat/vB, $0.11 for a typical transfer at a BTC price of $77,891:

Bitcoin fee rates right now (mempool.space)

For developers the RPC grows an options object: fee_rate_estimator accepts auto (the default, combined), block_policy (the old behaviour) or mempool_policy, unknown values are rejected, verbosity 2 adds mempool_health_statistics, and in auto mode the response names the estimator it used. The block policy data moves to fees/block_policy_estimates.dat and is migrated on first start. The wallet's own coin selection uses the combined estimate. What this does not change: the fee is still your choice, replace-by-fee and child-pays-for-parent still rescue a transaction that paid too little, and the sat/vB tiers on our fees guide refresh every minute from the mempool.

5. What changes for node operators?

Upgrade, and check which branch you are on. 29.x reached end of life on October 27, 2026 and 29.5 of October 28 is its final release, so a node on 29.x will get no further fixes; 30.x stays maintained until 33.0 ships, 31.x until 34.0 and 32.x until 35.0. Upgrading from an end-of-life version directly to 32.1 is supported, though a data directory migration can take time. Supported platforms are Linux kernel 3.17 or newer, macOS 14 or newer and Windows 10 version 1903 or newer.

Two defaults change your footprint. The default maxconnections rises from 125 to 200, and a new inboundrelaypercent option (default 50) caps the share of inbound slots given to peers that relay transactions; to keep the old behaviour run with maxconnections=125 and inboundrelaypercent=100. Outgoing transaction relay is now rate-limited with a global backlog (txsendrate, default 14 transactions per second, 2.5 times that for outbound peers, plus a 12 MB per 10 minutes bandwidth cap). Automatically created Tor hidden services get proof-of-work defenses when the Tor daemon supports them. The RPC server no longer uses libevent, and a new rpcmaxconnections option (default 16) limits simultaneous HTTP clients.

Two options save disk and time. The transaction index stores less data: a rebuilt txindex takes less than half the space, but you only get the saving by deleting indexes/txindex in the data directory and restarting, which can take hours; the txospenderindex shrinks the same way. Block validation prefetches previous outputs in parallel with prevoutfetchthreads, default 8, maximum 16, 0 to disable. Legacy I2P ElGamal sessions will be removed by v34 and CJDNS support is under review, so operators relying on either should follow the next release notes.

6. What changes for developers and wallets?

The breaking change is PSBT version 2. createpsbt, walletcreatefundedpsbt, converttopsbt and psbtbumpfee now produce version 2 PSBTs by default; a new psbt_version argument selects version 0 for tooling that cannot parse v2 yet. If a signing device, coordinator or script in your flow has not been tested with PSBTv2, pass the argument before upgrading the node it talks to.

Several fields and options are deprecated: vsize in the mempool RPCs and getrawtransaction (use vsize_adjusted, or vsize_bip141 for the raw BIP 141 size), the walletrbf startup option and the bip125-replaceable key (nodes have relayed replacements of any transaction since Core 28), and the removeprunedfunds RPC, which now needs deprecatedrpc=removeprunedfunds. Wallet names with dot path elements, or a wallet named with a bare slash, are rejected.

New in the RPC surface: exportwatchonlywallet, addhdkey and derivehdkey; send and sendall are no longer marked experimental; getblockchaininfo reports assumeutxo background validation progress; getbalances adds a nonmempool balance; getnetworkinfo reports the asmap version; exportasmap and getopenrpcinfo; a bitcoin-util getchainparams command. The custom HTTP server is stricter about headers, so check any client that sends unusual ones. None of this touches how a transaction is built or broadcast, so SDKs that talk to a node over standard RPC, including ChainGate, keep working.

7. Do Bitcoin users need to do anything?

No. 32.1 changes no consensus rule, so there is no fork, no new coin and nothing to migrate; your keys, addresses and balances are the same. If you run a light wallet or keep coins on an exchange, the upgrade happens on other people's machines.

What you may notice is a wallet connected to a Core node proposing lower fees in the hours after a busy period, since the estimator now reads the mempool. If you run your own node, upgrade; if you are on 29.x, you are on an unmaintained branch as of October 27. Anyone telling you to move or "update" your bitcoin because of a Core release is running a scam.

8. What is confirmed and what is still open?

9. What comes next?

The next dated item is the disclosure of the three vulnerabilities fixed in 30.0, which the release notes promise two weeks after the release, so around November 10, 2026. We will add it here, together with any 32.x maintenance release. The update log below records what changed and when.

In the meantime, the Bitcoin fees guide shows the live sat/vB tiers the new estimator is catching up with, the transaction hash guide explains how to follow a transaction that is waiting, and the Binance Pool shutdown piece covers what happens to stuck transactions once that accelerator closes on November 10.

Updates to this article

• October 31, 2026: first published. Dates from the Bitcoin Core release schedule issue, the bitcoincore.org download server and release pages; vulnerability details from the three disclosure posts of October 28; release contents from the 32.1 release notes and the lifecycle page.

Frequently asked questions