Bitcoin Core 32 enters testing with lower-only fee estimates

Bitcoin Core 32 entered its release-candidate cycle on Sept. 14, according to the project schedule, with draft changes that add eight parallel workers for validation reads and let current pending transactions lower fee estimates. Oct. 10 is the target for the final release tag, not a confirmed release date.

The update does not change Bitcoin's consensus rules, the rules that determine whether blocks and transactions are valid. For node operators and miners, the changes concern processing speed, fee estimates and software compatibility, with the draft release notes also identifying wallet and server changes whose final contents remain unsettled.

Where validation gets faster

Core 32 fetches input prevouts, the earlier transaction outputs being spent, from the chainstate database in parallel while connecting blocks. This helps when validation needs disk reads: workers load the data into a cache before the main validation thread asks for it, while that thread performs the same checks as before.

The validation pull request reports gains during initial block download, chainstate rebuilding and worst-case processing of blocks at the chain tip. Those are developer measurements, not an independently established speedup for every node or mining deployment. The benefit depends on validation needing data from disk.

Operators can control the worker count with -prevoutfetchthreads, which defaults to 8, accepts up to 16 and disables parallel prefetching at 0. The change brings data into memory earlier; it does not remove validation work or change which blocks the node accepts.

Fee estimates can move lower

The estimatesmartfee RPC, a command applications use to request fee estimates, combines the existing block-based estimator with a new estimator using the mempool, the node's pending transactions. When both succeed, Core returns the lower result. The new estimator can therefore lower the block-based estimate, but cannot raise it.

Core's wallet uses this combined estimate by default. The new estimator requires recent blocks to indicate a healthy mempool; when pending transactions are too sparse, it falls back to the higher of the minimum relay fee rate and the current mempool minimum. No quantified reduction in actual transaction fees or miner fee revenue has been established.

Applications must also handle failures: the combined estimate returns an error if either estimator cannot succeed, including while the mempool loads or when too few recent blocks have been observed. Clients can preserve the previous behavior by setting fee_rate_estimator to block_policy; mempool_policy selects only the new estimator, while the default none combines them.

Successful combined responses identify which estimator supplied the result, and verbosity of 2 or higher returns mempool health statistics. Wallet transaction-creation responses also change fee_reason to explain whether the selected rate came from estimation, the mempool minimum, a fallback or the minimum required.

Mining clients need compatibility changes

The IPC mining interface, which lets separate mining software communicate with Core, will reject out-of-range block-template settings that it previously adjusted silently. Node startup also rejects -blockmaxweight when it is below -blockreservedweight, so an invalid configuration can no longer depend on Core correcting that relationship.

Mining clients must regenerate their interface bindings from the updated mining.capnp schema to use the changed BlockTemplate.submitSolution method. It now returns rejection reasons and debug details alongside the success-or-failure result. The previous method returns an error directing clients to update, and duplicate block submissions now return failure with the reason duplicate, instead of success.

Wallet defaults and server limits

Four transaction-building commands switch to PSBT version 2, the format for partially signed Bitcoin transactions, by default: createpsbt, walletcreatepsbt, converttopsbt and psbtbumpfee. Each gains a psbt_version argument to select the output format. Separately, the wallet notification fix makes placeholder replacement treat wallet names literally.

Core also replaces its libevent HTTP server with a newly written server. Operators gain -rpcmaxconnections, which defaults to 16 simultaneous HTTP clients; the draft notes suggest a lower setting for systems with limited resources. The server will also attempt to reserve file descriptors for its sockets.

What to watch next

For transaction-index users, the draft notes describe a disk saving that requires a separate rebuild: a fully recreated -txindex takes less than half the space. Existing indexes remain compatible, but upgrading alone does not shrink them. Operators seeking that saving must recreate the index.

The schedule marks the Sept. 14 start of the release-candidate cycle, including tagging and releasing v32.0rc1, as complete. The final v32.0 tag remains an Oct. 10 aim, and the release notes remain a draft.