Bitcoin Core 31.0 Privacy Feature Exposed IP Risk in Edge Cases

Bitcoin Core’s latest attempt to strengthen ‘privacy’ has come under scrutiny after researchers found that a new transaction-broadcasting option could, in specific edge cases, expose a node operator’s real IP address—undercutting the very anonymity protections many users rely on.

MEXC Ventures said in a recent research note that Bitcoin Core version 31.0’s privatebroadcast option may bypass Tor proxy settings under certain network conditions, potentially allowing direct IPv4 or IPv6 connections during transaction relay. The issue was formally acknowledged in June 2026 when the Bitcoin Core development team released version 31.1, which includes a fix.

Bitcoin Core is the reference implementation used by a large share of the global Bitcoin (BTC) node network, serving as a baseline for transaction validation, block propagation, and enforcement of protocol rules. The problem centers on privatebroadcast, a feature introduced in 31.0 to make it harder for observers to identify the origin of a transaction by relaying it through third-party nodes rather than broadcasting directly.

According to MEXC Ventures, the vulnerability emerged not from the intended broadcast path but from a ‘fallback’ scenario. Bitcoin Core 31.0 attempts to establish encrypted connections using BIP324’s v2 transport protocol. If the v2 handshake fails, the client automatically falls back to the legacy v1 connection method. In the affected implementation, that fallback could proceed without preserving Tor proxy routing—resulting in an attempted direct connection over standard IP networking.

In practical terms, a mechanism designed as a ‘privacy shield’ could become an IP disclosure channel when the network environment forces the software onto an exception path. MEXC Ventures said the risk underscores a recurring security lesson in distributed systems: implementation details around error handling and recovery logic can be as consequential as the headline feature itself.

The reported impact is narrow but significant. The behavior is triggered when a node operator enables privatebroadcast, transmits a transaction via the sendrawtransaction RPC method, and runs the node in an environment where outbound IPv4 or IPv6 connectivity is available. By contrast, wallet RPC-based transaction submission, Tor onion address connectivity, and I2P-based connections were not identified as directly affected. Operators who already route all network traffic exclusively through Tor or I2P were also assessed to be in a comparatively safer posture.

The episode matters because Bitcoin’s ledger is public by design: anyone can inspect transaction flows on-chain. But if an adversary can link the first node to propagate a transaction to a real-world network address, that metadata can become a powerful input for attribution—especially when combined with ‘on-chain analytics’ and other off-chain signals. In that sense, the bug is not just a software quirk, but a privacy-sensitive networking gap with implications for Bitcoin’s broader ‘censorship-resistance’ and anonymity assumptions at the user and infrastructure layer.

Bitcoin Core 31.1 addresses the issue by ensuring Tor proxy settings persist even when the client falls back from BIP324 v2 to v1 transport. The release also includes a range of broader updates, including P2P networking improvements, strengthened wallet migration stability, updates tied to MuSig multisignature code, and maintenance work across the build and testing systems—signaling that the patch was delivered alongside wider reliability work rather than as a single isolated hotfix.

Before upgrading, three interim mitigations were commonly highlighted: disable privatebroadcast; disable BIP324 v2 transport and force legacy v1 behavior; or route all outbound IPv4 and IPv6 traffic through Tor to eliminate direct-connect paths regardless of fallback logic. The third approach was viewed as the most conservative because it blocks IP-level leakage at the network layer, though it can carry operational and performance trade-offs depending on infrastructure constraints.

The disclosure also landed amid a separate technical debate inside the Bitcoin Core community over Replace-by-Fee (RBF) signaling. Some developers have argued that explicit RBF signaling unnecessarily reveals on-chain information and should be removed, while others counter that eliminating explicit signaling can increase complexity by requiring more granular, per-input sequence number management. With many transactions already following established sequence-number conventions, critics of the change warn that removing signals could impose greater engineering burden than expected.

For the market and the ecosystem, the incident reinforces an uncomfortable point: ‘privacy’ in Bitcoin is not guaranteed by cryptography alone. Connection encryption, proxy configuration, and—crucially—how software behaves during failures and fallbacks all determine whether anonymity holds up in real-world conditions. As Bitcoin Core evolves, attention is increasingly shifting from feature intent to the rigor of edge-case verification across the full connection lifecycle.

Ultimately, the Bitcoin Core 31.0 issue is a reminder that a security feature’s mere presence is not enough. When ‘privatebroadcast’ can become an IP exposure pathway under certain conditions, it highlights the need to audit not only the primary route but every contingency path that the software might take. MEXC Ventures said future Bitcoin Core work will likely place greater emphasis on validating end-to-end networking flows, including fallback behavior, as a central pillar of practical privacy.