Stats on compact block reconstructions

Detailed logging and analysis using the debug=cmpctblock setting on monitoring nodes have illuminated the frequency with which nodes require additional getblocktxn → blocktxn round trips for block completions due to missing transactions. The study carefully tracked several variables: the number of prefilled transactions, those utilized from the mempool, extra pool, and those requested anew. It was observed that changes in node configurations—such as increasing inbound connections or enabling full-RBF (Replace-By-Fee) modes—notably influenced block reconstruction success rates. For instance, enabling mempoolfullrbf=1 led to marked improvements in some nodes, suggesting that broader adoption of this policy could benefit network-wide block propagation times.

The performance of compact block relay is closely tied to the operational mode—high-bandwidth versus low-bandwidth. High-bandwidth mode, employed for the majority of blocks, allows for more efficient reconstructions with fewer transaction requests required post-announcement. Conversely, the low-bandwidth mode, which validates blocks before sending them, reveals opportunities for optimization, particularly in pre-filling unknown transactions to reduce subsequent requests. However, such enhancements are yet to be realized in the current implementation, as noted in outstanding TODOs. The anticipated release of Bitcoin Core v28.0, which will enable full-RBF by default, presents a timely moment to revisit these architectural choices and possibly implement such optimizations.

A deeper dive into the mechanics of block reconstruction underscores the importance of the "extra pool"—a limited buffer (defaulting to 100 transactions) maintained to store recently evicted or replaced transactions. Unlike the main mempool, whose contents are widely relayed and thus likely convergent across nodes, extra pools are highly individualized, reflecting each node's unique peer relationships and rejection history. This individuality means that prefilling transactions from an extra pool may not be as redundant as previously assumed, given the substantial variance between different nodes' extra pools. Furthermore, the handling of RBF-replaced transactions, where original versions are relegated to the extra pool while replacements continue to propagate, highlights the nuanced role this buffer plays in maintaining block assembly efficiency under dynamic mempool conditions.

Bandwidth and congestion control emerge as central considerations in optimizing compact block propagation. Developers are advised to limit prefill sizes—typically to around 10kB, as outlined in BIP152 implementation notes—to prevent unnecessary expansion of CMPCTBLOCK messages and potential overflow of TCP windows. Empirical studies confirm that prefilling, when kept within the boundaries of the receiver's TCP window, can dramatically improve reconstruction rates without incurring additional latency. Yet, if prefill data exceeds the window, the benefits diminish due to induced round-trip delays. These findings underscore the necessity for dynamic tuning of prefill parameters, potentially informed by real-time feedback from kernel-level congestion control mechanisms.

The investigation also brings to light the complexities introduced by orphan transactions—those referencing unavailable inputs. A significant proportion of rejected transactions during block reconstructions were attributable to missing or spent inputs, i.e., orphan status. While orphanage management remains an area ripe for further exploration, it is clear that optimal handling could reduce redundancy and streamline reconstruction workflows. Suggestions include iterating the orphanage during block reconstruction or refining policies to exclude orphans from extra pools entirely.

Privacy implications and protocol-level innovations also figure prominently in ongoing discussions. The risk of exposing node-specific mempool policies or inadvertently revealing non-standard transactions through compact block announcements has prompted proposals for segregated user-pool mempools and more sophisticated prefill selection heuristics. Additionally, the integration of Forward Error Correction (FEC) techniques and advanced coding strategies, such as minisketch, promise to further reduce message sizes and accelerate recovery from missing transactions, albeit with deployment challenges related to licensing and network compatibility.

Significant real-world events have directly affected network performance and reconstruction metrics. Notably, a period characterized by unsolicited chains of rune mint transactions and aggressive burning behavior, as documented in examples, introduced considerable divergence among node mempools. This practice ceased abruptly on October 18, 2026