# Stats on compact block reconstructions

**URL:** <https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052>\
**Category:** Protocol Design\
**Created:** [August 2, 2024, 11:58am UTC](https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052 "2024-08-02T11:58:02Z")\
**Posts on this page:** 1\
**Showing post:** 54

<div class="post-metadata">

**Author:** ![ajtowns](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/ajtowns/32/417_2.png) [@ajtowns](https://delvingbitcoin.org/u/ajtowns)\
**Post date:** [September 28, 2026, 3:29am UTC](https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/54 "2026-09-28T03:29:11Z")

</div>

> [@0xB10C](#):
>
> compact block relay is essentially broken right now…

I don’t think that’s a fair conclusion – compact block relay still reduces bandwidth and latency substantially (vs header/block messages) by only requiring the missing txs to be relayed, rather than the entire block; and I’m still mostly seeing sub-second block reconstruction times.

I think I’ve seen both a bunch of double-spends amongst txs at the top of the mempool (could be either random, or people competing for runestone auctions or similar?), and also some apparent rbf failures (ie a higher feerate collection isn’t getting to my mempool due to 1p1c not being sufficient?). Conflicts between the old greedy-ancestor template building and the new cluster mempool approach might also be having some impact? Not really sure.

---

_[View the full topic](https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052)._