Bitcoin Core 31.1rc1 Closes the v31.0 PrivateBroadcast IP Leak

Bitcoin Core published a new release candidate, v31.1rc1, for testing on June 29, 2026. The candidate closes an IP-address leak that surfaced in v31.0’s -privatebroadcast feature. Release notes, binaries, and source archives are linked from the Bitcoin Core Project’s main channels.

The fix list runs across validation, networking, the wallet, MuSig aggregation, and a stack of build and test cleanup. Bitcoin Core Project framed v31.1rc1 as a minor release that follows v31.0, the mainnet version that shipped in April. That prior build had introduced a private-broadcast option meant to keep transaction originators off clearnet. The leak that surfaced in that same release made the privacy promise unreliable under one common network route. Bitcoin Core Project posted the announcement with release notes, binaries, and source archives in a single bundle, and the standard bug-report channel is the GitHub issue tracker.

What Bitcoin Core 31.1rc1 Sets Out to Fix

v31.1rc1 is the test-phase build that runs ahead of v31.1 stable. The release notes, hosted on the v31.1rc1 tag of the bitcoin/bitcoin repository, organize the patches by module. The list begins with a PrivateBroadcast fix, then walks through validation, LevelDB, P2P, wallet, MuSig, build, test, fuzz, util, docs, CI, and a miscellaneous group. Test scripts and CI configuration take up several pages within the notes.

v31.0 had also introduced cluster mempool, a redesigned -dbcache default of 1024 MiB on systems with at least 4096 MiB of RAM, and an embedded -asmap dataset dated to 2026-03-05, per the v31.0 release notes. Those changes are not modified in v31.1rc1, but they sit one release behind the leak that prompted it. The candidate therefore reads as a focused patch on top of v31.0, not a redo of it.

Behind the headline privacy fix, the v31.1rc1 release notes list validation, wallet, MuSig, and LevelDB as targeted single-PR changes. The MuSig fix in PR #35316 rejects an empty pubkey list inside GetMuSig2KeyAggCache, so signature aggregation cannot run against a blank key set. Wallet work covers a BDB page LSN check during migration and a more accurate input-size estimate that uses the outpoint. A handful of additional items handle docs, a fuzz timeout, util settings writes, and a LevelDB seek-compaction toggle.

The PrivateBroadcast IP Leak in v31.0

v31.0 shipped -privatebroadcast as a way to keep transaction originators off clearnet. With the flag on, the sendrawtransaction RPC announces transactions only to peers reachable through Tor or I2P. Bitcoin Core disclosed the vulnerability separately, noting the flaw could potentially expose the transaction initiator’s IP address to the receiving node.

The disclosure laid out three user-side mitigations to apply until v31.1 ships stable: disable -privatebroadcast, disable v2 transport, or route IPv4 and IPv6 outbound traffic through Tor. Wallet RPC, onion, and I2P node connections were unaffected by the leak from the start. The v31.1rc1 patches rebuild the network code path; the user checklist stays as-is. A recent Orchard pool emergency patch in Zcash followed a comparable pre-stable cycle on a separate privacy bug.

• Disable -privatebroadcast on any node that also uses sendrawtransaction.
• Disable v2 transport at the network layer.
• Route outbound IPv4 and IPv6 traffic through Tor before upgrading to v31.1.

Tracing the Tor Bypass

Bitcoin Core’s network layer defaults to BIP324 v2 transport for new outbound connections when a peer supports it. That handshake can fail and force a retry under v1 transport.

That retry path was the leak. Under v31.0, the new outbound connection could go directly to the peer’s IPv4 or IPv6 address, bypassing the user’s Tor or I2P proxy while a still-populated address manager entry kept the clearnet route alive. Tor or I2P, intended as the only outbound channels for private broadcasts, sat unused on that retry path.

The two PRs that close it in v31.1rc1 are PR #35032, which stops addrman updates during private broadcast connections, and PR #35410, which forces v2-to-v1 reconnections to honor the user’s proxy override. Wallet RPC, onion, and I2P node connections were unaffected from the start, per the disclosure. Bitcoin Core Project described the fix as eliminating the fallback that previously leaked across clearnet. The June 2026 vulnerability breakdown noted the leak hinges on a v2-to-v1 reconnection that re-uses a clearnet entry.

Beyond the Privacy Fix in v31.1rc1

The wallet, validation, MuSig, and LevelDB fixes are concentrated in a small number of pull requests. Each is a targeted change against a specific subsystem, not a refactor.

PR #35227 in the wallet adds a final BDB page LSN check during migration, catching a state mismatch where the migration script previously finished without verifying the last page. PR #35228 now uses the outpoint when estimating input size, replacing an estimate that did not account for the exact utxo being spent. Together they narrow two failure modes that could surface during an upgrade from an older Bitcoin Core release.

Validation work brings two changes around precomputed data and chainstate compaction. PR #35209 corrects the lifetime of precomputed tx data, so the cache cannot outlive its allocator during a unit-of-work shutdown. PR #35465 keeps the UTXO chainstate more compact through regular compaction runs. MuSig receives a single patch in PR #35316, where GetMuSig2KeyAggCache now rejects an empty pubkey list and blocks signature aggregation against a blank key set.

The LevelDB backend takes one change in PR #61 of bitcoin-core/leveldb, disabling seek compaction to keep the IO profile predictable under chainstate writes. A documentation PR (#35283) flags the -DWITH_ZMQ=ON build flag in the BSD build guides. The util layer in PR #35384 refuses to rename settings.json if the underlying write fails, so local node settings cannot be lost to a partial write.

Test Cleanup and the CI Migration

The rest of v31.1rc1 covers test, fuzz, build, util, and CI. The test suite receives its own set of pull requests, including socket race cleanup on a gracefully closed socket and clean SOCKS5 server shutdown. Another test PR adds a missing timeout_factor scale to the tool_bitcoin_chainstate.py harness, while another removes address type restrictions inside a PSBT test. Fuzz work shows up in PR #35289, which fixes a timeout in the txorphan target.

Continuous integration is the broadest single block in v31.1rc1. PR #35378 migrates the CI runners from cirrus to warpbuild, with PRs #35408 and #35430 layering warp caching on top, and PR #35447 routing docker buildkit through the warpbuild cache. The shared test path also picks up the LevelDB compaction toggle and a handful of miscellaneous build fixes.

RBF Signaling Outside This Release

RBF signaling discussion is independent of v31.0 and v31.1rc1, but the same week’s release notes share the floor with it. Bitcoin developers are weighing whether to remove explicit Replace-by-Fee signaling from the Bitcoin Core wallet entirely.

The argument, made by developer rkrux on the project’s channels, is that full-RBF is now standard policy across the network. RBF’s BIP 125 signal has therefore become redundant: it leaves a fingerprint of intent on-chain that no longer corresponds to a meaningful choice by the sender. The same wallets continue to choose sequence numbers per input, so the on-chain fingerprint is not the only one a sender leaves today. Community feedback has been measured rather than unanimous, with developers like Murch arguing the change needs more than a simple signal-removal step at the relay layer.

About 75% of transactions already use specific sequence numbers, with MAX-2 the most common choice, per recent community reporting. Wallet implementers also push for a wallet-side default that reflects broadly accepted best practices for sequence number selection, which would handle the change at the sender rather than at the relay-policy layer. RBF signaling is not removed in v31.1rc1 and is not on the v31.1 stable cutoff list. The discussion is open-source-archive material for readers following where transaction-replaceability policy goes next, separate from the leak fix that opened this release window. The active thread sits on Bitcoin Core’s developer mailing list, with Murch and rkrux both contributing follow-ups during June 2026.

Putting v31.1rc1 Through Its Paces

A new release candidate of Bitcoin Core, v31.1rc1, is available for testing. This is a new minor release, and follows v31.0.

Bitcoin Core Project (@bitcoincoreorg) posted the June 29 v31.1rc1 announcement on X on June 29, 2026, with the release notes at the v31.1rc1 tag and the binaries under bitcoincore.org/bin/bitcoin-core-31.1/test.rc1/. The candidate carries the release-candidate flag the project uses for pre-stable builds. The release targets the same operating systems listed in the v31.0 notes: Linux Kernel 3.17 or newer, macOS 14 or newer, and Windows 10 (version 1903) or newer. The v31.1rc1 release notes reprint the same compatibility statement verbatim.

The v31.1rc1 release notes link the GitHub issue tracker as the bug-report channel, in line with the standard RC process. Bitcoin Core Project invites the community to flag unexpected behavior during the test window. For related reading on node operators being asked to upgrade, see a recent Solana validator stability upgrade advisory in the same stretch.

1. Pull the v31.1rc1 binaries from bitcoincore.org/bin/bitcoin-core-31.1/test.rc1/, or clone the bitcoin/bitcoin repository at the v31.1rc1 tag.
2. Run the candidate on signet or testnet rather than mainnet, and apply one of the mitigations from the v31.0 advisory if any production node has -privatebroadcast enabled.
3. Exercise the -privatebroadcast path with Tor and a SOCKS5 proxy override, and confirm that the local address manager does not gain entries for the peers used only for the private broadcast.
4. Report bugs through the GitHub issue tracker, the bitcoin-core-dev mailing list, or the Bitcoin Core Project social channels; everyone in the credits list is reachable through GitHub.

Frequently Asked Questions

What does v31.1rc1 fix that v31.0 didn’t?

v31.1rc1 specifically closes an IP-address leak that surfaced in v31.0’s -privatebroadcast feature. The release notes place the PrivateBroadcast section at the top, with PR #35032 preventing address-manager updates during a private broadcast connection, and PR #35410 forcing v2-to-v1 reconnections to honor the user’s proxy override. Validation, wallet, MuSig, and LevelDB each receive smaller, targeted changes on top of the privacy fix.

Does the -privatebroadcast IP leak affect me?

The leak affects a narrow slice of users: those running Bitcoin Core 31.0 with -privatebroadcast enabled, broadcasting transactions through the sendrawtransaction RPC, and able to reach outbound IPv4 or IPv6 peers directly. Wallet RPC, onion, and I2P node connections were unaffected from the start. The v31.0 disclosure lists three pre-v31.1 mitigations: disable -privatebroadcast, disable v2 transport, or route IPv4/IPv6 outbound traffic through Tor.

What should I do before v31.1 ships stable?

Wait for the stable v31.1 release, and read the release-notes changelog at that point. Node operators who cannot yet upgrade can apply one of the three mitigations from the v31.0 disclosure: disable -privatebroadcast, disable v2 transport, or route IPv4/IPv6 outbound traffic through Tor. Operators running a wallet or a non-private broadcast path were never exposed to the leak.

When will Bitcoin Core 31.1 be released?

Bitcoin Core framed v31.1rc1 as the test-phase build ahead of v31.1 stable, asking the community to test and report bugs. The repository doc/release-process.md and the v31.1rc1 release notes announce rc1 availability, with subsequent release candidates historically published until no critical problems remain. The official release date for v31.1 stable is not printed in the rc1 announcement.

How do I test the release candidate?

Download v31.1rc1 binaries from bitcoincore.org/bin/bitcoin-core-31.1/test.rc1/ or build from source at the v31.1rc1 tag of the bitcoin/bitcoin repository. Test the -privatebroadcast and proxy override paths on testnet or signet, and report issues through the GitHub issue tracker.