Compact blocks are primarily delivered through high-bandwidth mode, accounting for approximately 75% of deliveries. This mode involves peers sending a cmpctblock message before the validation of the block, contrasting with the low-bandwidth mode where a peer sends an inv/headers message, followed by a getdata(compactblock) request from the receiver to obtain the compact block.

A noteworthy observation is that compact blocks received via high-bandwidth mode generally request transactions less frequently than those received in low-bandwidth mode. This is advantageous as it indicates a more efficient process of block reconstruction without needing additional transaction information. Additionally, it has been observed that nearly all compact blocks come with only the coinbase transaction pre-filled, suggesting an area for optimization in the low-bandwidth mode.

In the case of low-bandwidth mode, where blocks are fully validated before being announced, there exists potential for improvement. Specifically, the sender could pre-fill transactions it was previously unaware of, potentially reducing the necessity for subsequent transaction requests. However, a review of the Bitcoin Core implementation indicates this optimization has not yet been implemented, as noted in a TODO within the codebase.

The upcoming adoption of Bitcoin Core v28.0, which introduces full-RBF (Replace-By-Fee) by default, provides an opportune moment to reassess these dynamics. Should the performance disparities between low- and high-bandwidth modes persist, it would merit dedicating time to implement the aforementioned improvements, potentially enhancing the efficiency of low-bandwidth compact block delivery and reconstruction.