Bitcoin Core 32.1 Fixes Conditional IP Exposure in Private Broadcast

Bitcoin Core announced version 32.1 on Oct. 27, giving full-node operators a fix for an IP-exposure path in its optional private-broadcast feature and changing RPC and peer-connection defaults. Full nodes verify blocks and transactions before relaying them across Bitcoin’s network.

The privacy issue involved transactions submitted through sendrawtransaction with -privatebroadcast=1. The documented scenario required Tor to be configured while direct IPv4 or IPv6 connections were allowed without a -proxy= setting. A peer could falsely advertise support for P2P v2; if that connection failed, a retry over v1 could connect directly over IPv4 or IPv6.

Version 32.1 caps the private-broadcast queue at 10,000 transactions and rejects new submissions when it is full. It also limits each transaction to 1,000 send attempts. Bitcoin Core released versions 31.2 and 30.4 for earlier branches. Version 31.2 includes the queue cap and marks private broadcast as experimental.

The update changes data returned by several mempool RPC commands. By default, getmempoolinfo no longer returns the deprecated fullrbf field, and specified mempool responses omit bip125-replaceable unless compatibility options are enabled. Four commands for creating partially signed Bitcoin transactions now default to version 2. Applications that rely on the removed fields may need to account for the change.

The default maximum for automatic peer connections rises from 125 to 200. Transaction-relaying peers can use up to 50% of inbound connection slots by default, and the related setting accepts values from 0 to 100.

Bitcoin Core also published three security advisories on Oct. 28 covering issues fixed across versions 29.5, 30.4, 31.2 and 32.1. Two issues were rated Medium and one Low. The Low-rated undo-file issue remains unresolved for affected 32-bit systems and nodes storing blocks on FAT32, a limitation detailed in earlier coverage of the Bitcoin Core disclosures.