#34322 node: Persist private broadcast transactions over node restarts

• Prevent transactions submitted via private broadcast from vanishing when a node restarts before completion

Introduces serialization and deserialization of pending private broadcast transactions to a privatebroadcast.dat file. In-flight transactions are dumped to disk during clean node shutdown and restored on startup if private broadcast is enabled.

Problem: Transactions submitted via sendrawtransaction with privatebroadcast enabled exist only in peer manager memory; a node restarting before private broadcast finishes permanently drops the transaction.

P3 · new feature

• P3 because prevents submitted private broadcast transactions from vanishing on restart
• Relief is limited to clean node restarts during the brief broadcast window
• May be superseded by a more comprehensive persistent broadcast pool

Improves transaction relay reliability for nodes utilizing private Tor/I2P broadcast by preventing submitted transactions from vanishing on restart. The problem is real but limited to clean restarts during the broadcast window, and discussion suggests a SQLite-backed broadcast pool might supersede this mechanism.

Membership: Modifies the private broadcast relay subsystem in net / peer manager, labeled Private Broadcast.

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

• Needs rebase due to merge conflicts
• Author marked PR as draft to rework the architecture in PR #34707

The PR has merge conflicts with the base branch and the author has been silent for 199 days after opening related PR #34707.

Author status: silent since 2026-03-02, marked PR as draft and opened PR #34707 as an initial step toward a reworked architecture

Open concerns:

• Persisting transaction data to disk on broadcaster-only nodes introduces disk privacy considerations if unencrypted.
• A simple shutdown-dump file does not protect against crashes or unclean shutdowns, prompting suggestions to build a persistent broadcast pool instead.

Resolved concerns:

• Permissions on the dat file should be restricted (0600) to protect private broadcast records.
• Removing the dump file early in the startup path ensures records do not linger on disk.

• Strong concept support because preserving transactions outweighs disk storage concerns (vasild)
• Concept approval noting this does not go far enough to handle unclean shutdowns (craigraw)
• Concern that storing unencrypted broadcast data expands the node disk attack surface (tankyleo)

Concept supported by vasild and craigraw; discussion on disk privacy and broadcast pool scope

Reviewers agreed on the need to preserve private broadcast transactions over restarts, while discussing whether a file dump or SQLite broadcast pool is the best long-term architecture.

• vasild: 'Concept ACK... benefits of not losing the transaction if the node is restarted before a successful completion out-weight the concerns about storing the transaction on disk.'
• craigraw: 'Concept ACK. However, I don't think this change goes far enough...'
• tankyleo raised disk attack surface concerns on broadcaster-only nodes; andrewtoth and vasild responded with mitigations.

Review verdicts (DrahtBot): 0

• Concept ACK: vasild, craigraw

Enables:

• #34707

File list not available for this run.

This PR persists in-flight private broadcast transactions to a privatebroadcast.dat file across graceful daemon restarts. It solves the issue where transactions submitted to peer manager are dropped if the node restarts before private relay completes. The concept received strong support from reviewers, though discussion raised questions regarding disk privacy and whether a SQLite-based broadcast pool is preferable. The PR has merge conflicts, has been marked draft, and the author has been inactive on it for over six months after opening PR #34707.