Keep in mind that compact weak-blocks need to be rate limited by a difficulty requirement. If this difficulty was say 1/10 or 1/100 of bitcoin, you’d be talking about potentially 10x or 100x more weak-compact-blocks than actual blocks. That’s a huge overhead for (most) txs you already have. This difficulty needs to be, at a minimum 1/F*(bitcoin’s difficulty) where F is the fraction of the network being mined by the pool accepting odd transactions. If we take Mara as an example, they have 2.9% of the hashrate as of today, so this rate parameter needs to be 1/35 bitcoin’s difficulty to be useful (or, on average, said pool won’t mine a weak block between actual blocks). Meaning up to 35x more weak-compact-blocks than bitcoin blocks. Using 32kb per compact block that’s 1.1MB additional bandwidth between blocks for these messages, plus the missing transactions.
If you send a weak-block Merkle proof in an INV, you can allow the difficulty requirement to be (much) lower. Even the worst case of a block of entirely of missing txs is then more efficient than the overhead of 35 weak-compact-blocks.
BTW I’m saying INV+weak-merkle-proof instead of weak-compact-blocks. Not both.
There’s clearly a trade-off here in how many txs are missing from other people’s mempools, which the sending miner doesn’t know, so would default to sending weak-compact-blocks for every one that matches the weak-target.
Cheers, – Bob