Transaction rate-limiting

This development results from an extensive three-year effort prompted by issues of excessive CPU consumption on certain mainnet debug-build nodes, which were traced back to inefficient iterator implementations in Boost and legacy anti-congestion mechanisms. The previous system, originally designed to limit network congestion by amplifying outbound transaction data per node, revealed limitations as transaction patterns evolved with innovations such as segregated witness and the increase in small, text-based inscriptions. These changes placed additional strain on the relay mechanism, resulting in reduced throughput and growing discrepancies between fee expectations set by miners and those used during relays.

To address these challenges, a comprehensive overhaul was implemented, including the elimination of per-peer transaction queues in favor of a single global queue. This restructuring enables more consistent CPU usage across all peers and improves overall management of high transaction volumes. Accompanying this change are new bandwidth rate limits that help prevent node overload during periods of elevated network activity, thereby strengthening both performance and stability. Together, these improvements not only resolve immediate practical concerns but also fortify the network against theoretical vulnerabilities, ensuring that Bitcoin nodes remain robust under varying conditions, whether due to increased adoption or targeted attacks.

Monitoring and diagnostics have also evolved alongside these technical upgrades. A peer-observer dashboard is actively employed to track node behaviors, with a particular focus on comparative analysis between different node versions—namely, running a 31.x node in parallel with multiple master/v32.0 nodes. This approach enhances the ability to identify, diagnose, and respond to anomalies or future incidents, underscoring a commitment to proactive system management.

Effective communication and mutual support within the developer community continue to play a vital role in driving progress. The sharing of encouragement and timely updates has proven instrumental in sustaining momentum and revitalizing efforts on ongoing projects. Recognition of these contributions highlights the importance of collaborative engagement and information exchange in fostering a productive and motivated professional environment.

Detailed adjustments have also been made to the propagation rates of transactions across network links. Transaction throughput is now regulated to approximately 24.5 transactions per second—comprising 17.5 transactions from outbound connections and 7 from inbound peers—with actual effectiveness influenced by overlapping announcements and duplicates. Modifications in inventory broadcast intervals for outbound peers, where privacy is less sensitive, have halved the time between broadcasts, now allowing 35 items every 2 seconds. This refined broadcasting strategy is further elucidated in the GitHub pull request on Bitcoin.

Crucially, the bandwidth budget operates on a global basis per node rather than per peer. Broadcast transactions are counted against the global limit regardless of how many peers receive announcements or subsequently request transaction bodies. For example, broadcasting ten 100kB transactions will count as 1MB towards the budget, whether announced to 10 or 100 peers, and independent of how many actually retrieve the full transaction data. Consequently, the actual outgoing bandwidth may vary widely—from as little as 3200 bytes (if none of the peers request the data) to as much as 100MB (if all peers request every transaction)—for the same 1MB budget allocation. This policy simplifies reasoning about bandwidth constraints, especially when considering adversarial network conditions, and ensures fairer, more predictable resource usage across the network.