Stats on compact block reconstructions

By utilizing debug=cmpctblock logging on monitoring nodes, researchers can assess the frequency with which additional transaction requests (getblocktxn → blocktxn) are needed due to missing transactions during block reconstruction. The analysis highlights several factors influencing these dynamics, including node configuration changes and shifts in mempool policies, such as the adoption of full-RBF (Replace-By-Fee) by default. Nodes operating with enhanced settings, such as increased inbound connections or altered transaction replacement policies, demonstrate measurable improvements in their ability to reconstruct blocks efficiently without requiring extraneous transaction data from peers. Periods of heightened mempool activity, often associated with network congestion, correlate strongly with decreased rates of successful compact block reconstructions, underscoring the importance of robust transaction management strategies.

The operational distinction between high-bandwidth and low-bandwidth compact block delivery modes plays a significant role in reconstruction performance. High-bandwidth mode, accounting for the majority of block deliveries, allows for expedited transmission since blocks are sent prior to validation, typically resulting in fewer required transaction requests. In contrast, low-bandwidth mode employs an initial announcement followed by a data request, generally leading to more frequent transaction requests due to the absence of prefilled transactions beyond the coinbase. This points to a clear area for optimization, particularly in the low-bandwidth context, where intelligently pre-filling transactions that are likely unknown to peers could substantially reduce unnecessary round-trips. Notably, enhancements to the Bitcoin Core implementation—such as those referenced in codebase TODOs and upcoming releases like v28.0—offer opportunities to revisit and improve these mechanisms, especially as full-RBF becomes the default policy.

A complex interplay exists between extra pool sizes, mempool configurations, and the efficiency of block reconstruction processes. The extra pool, governed by parameters like -blockreconstructionextratxn, retains a small number of additional transactions in memory to support reconstruction efforts. While variations in mempool size across nodes are best analyzed using simulation frameworks, the default extra pool's limited capacity means that it only marginally supplements the main mempool’s coverage. Furthermore, the diversity in extra pool contents among nodes is pronounced due to each node’s unique peer connections and transaction reception patterns, reducing the likelihood of redundancy and highlighting the individualized nature of transaction propagation across the network.

Recent empirical studies and experiments have sought to refine the prefilling strategy in compact block announcements. One promising approach involves prefilling transactions that were previously requested, those drawn from extra pools, and transactions prefilled in the compact block but absent from the local mempool. Research has shown that prioritizing the most recently received mempool transactions for prefilling significantly decreases the probability of needing further transaction requests, while prefilling based solely on fee or size offers little improvement. These findings are supported by practical experiments where nodes set with large extra pools observed marked benefits in reconstruction success rates, especially under conditions of mempool saturation. The importance of aligning prefill amounts with TCP congestion windows has also been highlighted, as excessive prefilling can lead to message fragmentation, increased round trips, and diminished gains from the optimization.

The debate surrounding the optimal management of orphan transactions and database-backed mempools continues to evolve. While retaining evicted or replaced transactions on disk—as exemplified by libbitcoin—offers potential advantages for block construction and transaction recall, it introduces significant risks, particularly concerning denial-of-service (DoS) vulnerabilities tied to unbounded disk usage. Pruning policies, both for in-memory pools and persistent stores, must balance the need for available transaction history with the imperative to defend against malicious exploits that could degrade system performance or stability.

Technical advancements in compact block relay protocols, such as the integration of Forward Error Correction (FEC) chunks and consideration of protocol-level nuances (e.g., TCP versus UDP for message transport), reflect a broader effort to minimize latency and bandwidth consumption during block propagation. Experiments have demonstrated that effective prefilling—bounded by protocol and network constraints—can yield substantial improvements in block propagation times. However, real-world challenges, including sudden bursts of replacement traffic, unsolicited direct transaction pushes, and adversarial behaviors exploiting anyone-can-spend outputs, continue to stress-test the robustness of these relay mechanisms.

Network-wide observations reveal that block propagation delays have generally improved for the majority of nodes, as evidenced by reductions in the 90% delay percentile, even if median delays remain unchanged. At the same time, a sharp decline in the percentage of blocks reconstructed without additional transaction requests indicates periods of systemic strain, often driven by off-chain events, rapid-fire auctions, or strategic transaction chains designed to game mempool policies and mining incentives. These incidents underscore the intricate relationship between network topology, transaction dissemination practices, and the effectiveness of compact block relay protocols.

Ongoing research and experimentation—including the deployment of new logging metrics, comparative testing between legacy and updated node configurations, and rigorous statistical analyses