Bitcoin Core 31.1 Fixes a Disk-Thrashing Chainstate Bug

Bitcoin Core released version 31.1 on July 8, a maintenance release whose headline fix stops the software from repeatedly rewriting large portions of its chainstate database during normal operation. The defect generated excessive disk activity on machines doing nothing more than following the chain; the release addresses it with regular chainstate compaction and by disabling seek compaction in LevelDB, the key-value store the database uses. The same version closes a privacy hole in which some connections made with PrivateBroadcast enabled were routed over the clearnet instead of the configured privacy network, an IP-leak path. It also adds Berkeley DB page-integrity checks during wallet migration, improves input size estimation and hardens MuSig2 key aggregation. Twenty contributors are credited on the release.

The Chainstate: A Database of What Is Currently Spendable

Bitcoin Core is the reference implementation of the Bitcoin protocol, the software that most full nodes run to validate blocks and relay transactions independently of anyone else. Alongside the block files, each node keeps a chainstate database: the set of unspent transaction outputs, meaning every coin that exists and has not yet been spent, along with where and under what conditions it can be spent. That set is what a node consults to decide whether an incoming transaction is valid, and it is why a node does not have to replay the entire history every time a block arrives. It is also the part of a node's storage that changes constantly, because every block spends some outputs and creates others.

Rewriting large parts of that database when only a small part has changed is expensive in the way that matters most to the operators who run the network's infrastructure. Sustained write volume slows initial synchronization and block validation, competes with whatever else the machine is doing, and wears out consumer solid-state drives, which have a finite number of write cycles. On the low-power hardware that a large share of hobbyist nodes run on, the cost is felt directly as a node that falls behind the tip.

The Fix: Scheduled Compaction and Seek Compaction Switched Off

LevelDB stores data in layered files and periodically merges them in a process called compaction, which rewrites data to keep reads efficient. One trigger for that work is seek compaction, which reorganizes files in response to read patterns rather than to how much has actually been written. Bitcoin Core 31.1 disables that trigger and instead compacts the chainstate on a regular schedule, so the rewriting happens when the node chooses rather than as a side effect of ordinary lookups. The change is invisible in behavior terms: the node validates the same rules, using markedly less disk throughput.

The Rest of the Release: PrivateBroadcast, Wallet Files and MuSig2

PrivateBroadcast sends a node's own new transactions over a privacy network so observers cannot tie a transaction to the IP address that originated it. The bug meant some of those connections took the clearnet path instead, defeating the purpose for users who had configured it deliberately. Separately, the wallet migration process, which converts older wallet files to the current format, now verifies the integrity of Berkeley DB pages as it reads them, so a damaged file is caught during migration rather than carried forward. The release also improves input size estimation, which feeds fee calculation when a wallet builds a transaction, and hardens key aggregation in MuSig2, the scheme that lets several signers combine their keys into one and produce a single joint signature.

What Changes Next: An Upgrade Nobody Is Obliged to Take

Version 31.1 is one of those maintenance releases that ship no new features, and consensus rules are untouched, so nothing about it forces a coordinated upgrade. Adoption will be gradual and voluntary, with the benefit accruing node by node. The release is supported on Linux kernel 3.17 and later, macOS 14 and later, and Windows 10 from build 1903. Twenty contributors on a point release is a fair measure of what routine maintenance of the reference client looks like: no new capability, a privacy regression closed, and unnecessary disk writes removed. Whether the compaction change fully resolves the I/O complaints will show up in reports from operators running it on constrained hardware.