# Package aware Fee estimator post cluster mempool

**URL:** <https://delvingbitcoin.org/t/package-aware-fee-estimator-post-cluster-mempool/312>\
**Category:** Implementation\
**Created:** [December 20, 2023, 9:33pm UTC](https://delvingbitcoin.org/t/package-aware-fee-estimator-post-cluster-mempool/312 "2023-12-20T21:33:06Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![glozow](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/glozow/32/261_2.png) [@glozow](https://delvingbitcoin.org/u/glozow)\
**Post date:** [December 21, 2023, 11:11am UTC](https://delvingbitcoin.org/t/package-aware-fee-estimator-post-cluster-mempool/312/2 "2023-12-21T11:11:07Z")

</div>

> is it just better to track chunks?

My mental model for package aware fee estimation is that the fee estimator essentially tracks “bids” consisting of block height + feerate, and block processing sees which bids succeeded in how many blocks. A CPFP is a new bid that overrides the original one, though the original tx could theoretically be mined by itself, so I guess the hard part is checking which bids were “accepted.”

Theoretically, a chunk can represent a bid, i.e. count as 1 data point. In the case of, say, an ephemeral anchors commitment transaction + sponsor, the idea is the transactions are inseparable and the package can be treated as a single transaction. All CPFPs, including batched ones, are like new bid for 1 big transaction at the chunk feerate.

And in practice, most clusters are probably 1 transaction, and most chunks will probably be mined in tact (?).

So yes, maybe just track chunks? Or I guess you could track chunks + the individual transactions, and only use exact matches after you linearize the block?

---

_[View the full topic](https://delvingbitcoin.org/t/package-aware-fee-estimator-post-cluster-mempool/312)._