Bitcoin Core 0.13.2 Release Guide for Node Operators

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

Wallet rejection behaviour

Previously a new transaction rejected for long unconfirmed chains returned an error but remained queued and could rebroadcast after restart. 0.13.2 returned success and retried mempool insertion with ordinary rebroadcast, removing the restart dependency. Applications needed to distinguish wallet creation from current mempool acceptance.

Abandonment and payment state

A wallet transaction not accepted into the mempool could be abandoned through the existing RPC or GUI. That did not prove no peer had seen or retained it. Payment systems needed wallet state, local mempool, conflicts and chain evidence before constructing a replacement or issuing another payment.

Chainwork-based initial sync

The release backported use of chainwork rather than height and header timestamps for initial-block-download decisions. This hardened readiness logic against misleading tall or time-shaped chains. Monitoring should read actual chain and validation state rather than reproduce obsolete height-only heuristics.

Compact-block corrections

Changes improved handling of invalid compact blocks, tried reconstruction from multiple announcements and adjusted high-bandwidth peer behaviour. Mining nodes needed malformed-message and multi-peer tests, because a correct happy-path reconstruction did not cover adversarial or divergent mempools.

RPC and serialization

The release tightened hash parsing, exposed serialization choices for SegWit-related RPC output and rejected unknown rpcserialversion values. Integrations needed byte-for-byte transaction tests for legacy and witness forms, including txid and wtxid expectations.

Fees, templates and relay

It disabled one-block fee estimates, fixed relay-priority calculation and corrected block size and weight calculation in template construction. Pools and wallets should test fee target availability and template accounting rather than assume a patch release preserves every numeric output.

Upgrade and recovery

Verify artefacts, stop cleanly, back up wallets and record mempool, index and pruning state. Exercise the changed wallet-rejection path, compact relay and failover before traffic. A rollback must reconcile transactions created under the new success semantics so they are not sent twice.

Conclusion

Bitcoin Core 0.13.2 changed important wallet and relay edge cases despite being a patch release. Safe rollout depended on explicit transaction-state, compact-block and serialization tests plus duplicate-payment prevention.