Bitcoin Core 0.15.1 Release Guide for Node Operators

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

Fork-safety peer handling

During initial sync, peers advertising less than minimum chain work could be disconnected and unsolicited low-work blocks could be ignored. Outbound peers known to trail the local tip were probed and eventually disconnected, with some peers protected to avoid excessive topology churn. These controls reduce wasted resources but do not turn peer observations into an independent source of consensus truth.

Stale-tip response

When the tip failed to advance for more than thirty minutes, the node could open an extra outbound connection and later remove the least useful peer. Monitoring had to distinguish this protective behaviour from a connection leak or attack. Test network partitions, delayed blocks, clock accuracy and recovery without hard-coding an invariant connection count.

Invalid-chain tracking

Known invalid blocks and descendants were tracked more consistently, and outbound peers serving headers on invalid chains could be disconnected. Compact-block announcements had a deliberate exception because BIP 152 allows relay before full validation. Incident analysis must preserve the exact message type, chainwork and validation state instead of treating every invalid-related peer event identically.

Mining weight policy

blockmaxweight had been preferred since 0.13, while blockmaxsize produced suboptimal selection and interface confusion. In 0.15.1 blockmaxsize was deprecated and used to derive an implied weight limit rather than directly cap template bytes. Pools requiring a byte ceiling had to filter templates themselves and then revalidate weight, fees, dependencies and coinbase commitments.

Wallet and file safeguards

The same wallet copy could no longer be opened twice, dumpwallet refused to overwrite an existing file, and backupwallet failed when destination equalled the source. These checks prevent destructive mistakes but automation should use unique, permission-restricted paths and verify the resulting backup. A successful RPC does not prove restorability; conduct an isolated restore and rescan.

RPC compatibility

listsinceblock rejected unknown block hashes instead of returning transactions since genesis. Getmininginfo lost currentblocksize, and several wallet and bumpfee failures received more accurate error classes. Integrations should branch on documented meaning only after contract tests, because stricter errors can expose hidden assumptions that previously looked like successful empty results.

Upgrade and rollback

Verify artefacts, stop cleanly and preserve wallets, settings, prune state and chainstate capacity. Simulate stale tips, invalid headers, mining-template limits and backup failures on a replica. Downgrading below 0.15 requires reindex-chainstate and may force a pruned-node redownload, while wallet activity created under the newer release must be reconciled separately.

Conclusion

Bitcoin Core 0.15.1 strengthened peer, mining and wallet failure handling. Operators still needed exact compatibility tests and a rollback plan that respected both the 0.15 chainstate format and any newer wallet activity.