Bitcoin Core’s privacy promise depended on the retry

A privacy feature can protect the first connection and fail on the second. Bitcoin Core’s July 8, 2026 release, version 31.1, addressed an IP-address leak in private broadcast. Developers said some connections had used the public internet rather than the enabled privacy network, revealing a gap in the feature’s intended protection. [1]

The earlier developer disclosure described a failed v2 handshake followed by a v1 retry that could reveal the sender’s IP address to the receiving peer. A handshake is the opening exchange that sets up a connection. Here the revealing moment was the fallback, not a normal successful first attempt. [2]

This was narrower than a flaw in every Bitcoin wallet transaction. The notice said wallet commands such as sendtoaddress and sendall did not use private broadcast and were not affected. The problem concerned that feature under particular network and configuration conditions, not a finding that all users lost privacy. [2]

For an operator, the economic task starts with deciding whether its own transaction route uses the affected feature. If it does, testing failure and retry behavior belongs in release validation. That takes engineering time, but a check of the actual path could be more useful than spending equally on unaffected wallet operations.

Version 31.1 also addressed excessive disk work. Its notes said a database called chainstate had repeatedly rewritten large portions of itself during normal operation, causing excessive reads and writes. This was a separate developer-reported correction, not a measured saving for every operator. [1]

An operator would need to compare disk reads and writes on the same workload before translating the correction into a budget benefit. Reduced activity might free capacity without changing a fixed bill. Validation hours, rollout effort and any remaining performance limits still belong in the comparison. A privacy improvement cannot serve as a disk-cost benchmark.

The practical lesson is to test the path after failure. Does a retry still use the intended network? Does the deployed configuration behave like the validated one? Separately, test resource use. A successful first connection could miss the privacy issue; lower disk activity could say nothing about whether addresses remain protected.

The strongest reason to limit the economic story is its narrow, configuration-dependent scope. An unaffected service might get no privacy benefit from this correction. The records give no installation count or measured harm prevented, and correcting one route does not establish comprehensive anonymity. Operational importance should follow actual use, not the word privacy alone.

The useful next evidence is a deployed version and configuration that preserve the intended route after a failed handshake, plus comparable disk measurements. Unchanged disk activity or substantial rollout work would weaken a savings claim. The July records establish reported maintenance corrections; they do not establish universal cost reductions or a Bitcoin price effect.