The necessity for such a measure stems from the potential surge in the number of weak-compact-blocks, which could escalate to tenfold or a hundredfold compared to actual blocks if not properly regulated. This escalation is primarily due to the variance in difficulty levels that might be significantly lower than Bitcoin's standard, leading to an excessive overhead for transactions already present within the network.

The proposed solution to mitigate this issue involves setting the difficulty for generating these weak-compact-blocks at a minimum threshold relative to Bitcoin's difficulty, adjusted by the fraction of the network's hash rate contributed by the mining pool that accepts specific, potentially non-standard transactions. For instance, using Mara, which contributes 2.9% of the total network hash rate, as an example, the difficulty for these blocks would need to be adjusted to 1/35th of Bitcoin's current difficulty level. This adjustment aims to balance the frequency of weak-compact-blocks with actual Bitcoin blocks, potentially resulting in up to 35 times more weak-compact-blocks than Bitcoin blocks. The bandwidth implications of this approach are significant, with an additional 1.1MB required per block interval for the transmission of these messages, alongside the data for any missing transactions.

An alternative strategy to address the overhead associated with transmitting weak-compact-blocks involves the use of Merkle proofs within inventory messages (INV). By adopting this method, the requirement for the difficulty of generating these blocks can be substantially reduced. This approach hinges on the efficiency gained from only needing to account for the worst-case scenario, where a block consists entirely of missing transactions, rather than the cumulative overhead of multiple weak-compact-blocks. It is important to note that this recommendation advocates for the exclusive use of INV messages with weak-Merkle-proofs instead of supplementing them with weak-compact-blocks, highlighting a trade-off regarding the unknown quantity of transactions missing from other nodes' mempools. The decision to default to sending weak-compact-blocks for every matching weak-target underlines the inherent challenges in optimizing network efficiency while accommodating the variability in transaction propagation.