Bitcoin Core 0.15.0.1 Release Guide for Node Operators

This guide explains Bitcoin Core 0.15.0.1 release in plain English. It summarises the important changes, who they affect and what should be checked before an upgrade.

Startup crash cause

Some upgraded GUI clients retained a custom-fee radio selection that no longer existed in the 0.15.0 interface. Reading that invalid QSettings value could crash startup. The patch validated the state rather than assuming every saved preference matched the new UI. Headless nodes were not exposed through the same GUI path, but shared deployment procedures still needed version checks.

Configuration-state migration

User interface settings are persistent operational data even when they do not hold coins. Reproduce upgrades with old settings, unusual locale, stale fee selections and a clean profile. Confirm the wallet opens, the fee controls show a valid state and no setting silently changes transaction policy. Avoid deleting the profile before preserving evidence needed to diagnose the fault.

Inherited chainstate boundary

A first move from pre-0.15 software still converted the UTXO database. Downgrading to an older release required reindex-chainstate because the old version could not read the new format. For pruned nodes this could require a full redownload. Installing 0.15.0.1 directly did not bypass this compatibility rule.

Fee-estimate reset

The fee_estimates.dat format changed at the 0.15 boundary, so crossing it in either direction discarded estimates. After startup, the estimator needed enough fresh observations before reliable results were available and could return insufficient-data behaviour. Wallet and merchant services should use documented fallback policy rather than reuse a stale file or assume the GUI default.

Scope of the patch

The changelog contains the invalid custom-fee setting fix and updated manual pages. It did not redesign the multiwallet interface, chainstate conversion or wallet recovery rules. Treating every operational issue in 0.15.0 as fixed by 0.15.0.1 would overstate the patch. Tests should map each observed problem to an explicit release-note item.

How specialists test it

Node operators test the release on a representative non-production system. They check startup, normal operation, failure handling and restart before changing a live node. Connected wallets, monitoring and mining services should also be checked.

Rollback plan

Back up wallet, data and settings before patching, verify binary signatures and wait for clean shutdown. If already on the 0.15 chainstate, rollback within the 0.15 line avoids the pre-0.15 database mismatch but can restore the crash. A deeper downgrade requires rebuild planning and must preserve newer wallet transactions.

Conclusion

Bitcoin Core 0.15.0.1 fixed a specific saved-setting startup crash while retaining the larger 0.15 migration boundaries. Safe patching required realistic old-profile tests and the same chainstate, estimator and wallet rollback discipline as the major release.