#34457 wallet: add private broadcast support for wallet transactions

• Protect origin privacy for wallet transactions and periodic rebroadcasts
• Route wallet RPC and GUI transactions over short-lived Tor or I2P connections instead of clearnet

Extends the private broadcast feature (#29415) to wallet transactions, routing transactions created by wallet RPCs and the GUI through short-lived Tor or I2P connections when `-privatebroadcast=1` is set. It centralizes the Tor/I2P reachability check in `BroadcastTransaction()`, updates `CommitTransaction()` and `MaybeResendWalletTxs()` to use the private broadcast pathway, fixes an unhandled exception in the Qt send dialog, and adds functional tests.

Problem: While #29415 introduced private broadcast over Tor/I2P to protect transaction origin privacy, it was only hooked up to `sendrawtransaction`. Standard wallet transactions and periodic wallet rebroadcasts still leaked origin IP addresses over persistent clearnet connections.

P2 · new feature

• P2 because it brings substantial origin privacy improvements to wallet users
• Ensures transactions created directly in Bitcoin Core gain private broadcast protections

Substantial privacy improvement for wallet users. As andrewtoth and w0xlt noted, extending private broadcast to wallet transactions ensures that transactions generated directly within Bitcoin Core gain the origin privacy guarantees introduced in #29415.

Membership: Modifies `CommitTransaction()` and `MaybeResendWalletTxs()` in `src/wallet/wallet.cpp`.

Factors: security/stability 1, bug 0, performance 0, user value 2, leverage 1

P3 · new feature

• P3 because it connects the wallet into existing Tor and I2P broadcast transport
• The underlying P2P transport machinery was already established in earlier work

Worthwhile integration work that connects the node's wallet directly into the p2p private broadcast pipeline, though the p2p transport machinery itself was already established in #29415.

Membership: Carries the 'Private Broadcast' area label and integrates node transactions with Tor/I2P p2p broadcast transport.

Factors: security/stability 1, bug 0, performance 0, user value 1, leverage 1

• Needs rebase due to merge conflicts
• Review #34533 first as author is waiting for its rebroadcast logic before updating

The PR has merge conflicts with master and author activity has been paused for over 200 days while awaiting progress on #34533.

Author status: silent since 2026-02-25; indicated waiting for #34533 before rebasing

Open concerns:

• rkrux suggested splitting out the Qt exception handling fix and the test framework helpers into standalone PRs.
• The PR overlaps with and depends on resolving the rebroadcast logic in #34533.

Resolved concerns:

• An earlier proposal to track private broadcast state per transaction in wallet metadata was discarded in favor of checking the node's current `-privatebroadcast` setting.

• Broad concept support with no objections to wallet private broadcast
• Concept approval for extending private broadcast to wallet transactions (andrewtoth, Bicaru20)
• Agreed on simplifying rebroadcast model to follow #34533 (andrewtoth, w0xlt)
• Suggested splitting Qt exception fix and test helpers into standalone PRs (rkrux)

Concept supported with no objections; waiting on rebase over #34533

Reviewers strongly agree with bringing private broadcast support to wallet transactions. The remaining discussion centers on clean commit boundaries and coordination with #34533.

• andrewtoth and Bicaru20 gave Concept ACKs for the feature.
• w0xlt agreed with andrewtoth on simplifying the rebroadcast model to follow #34533.
• rkrux noted that the Qt exception fix and test helpers could be split into independent PRs.

Review verdicts (DrahtBot): 0

• Concept ACK: andrewtoth, Bicaru20

Depends on: #34533

File list not available for this run.

Extends the private broadcast feature (#29415) to wallet transactions, routing sends and periodic rebroadcasts through short-lived Tor or I2P connections when -privatebroadcast=1 is enabled. This eliminates an origin IP privacy leak where wallet transactions were still broadcast over persistent clearnet connections. Concept support is solid with Concept ACKs from multiple reviewers, but the branch has merge conflicts and has been waiting on author action since early 2026 pending coordination with #34533.