This is intended to be a performance optimization when generating a block template for mining. The issue is around how many transactions we end up looking at while iterating over the mempool during block construction.
At a high level, the mempool sorts transactions by ancestor feerate, and in the mining algorithm we iterate over those transactions in descending ancestor feerate order to select transactions for a block. As we select transactions, we have to do some bookkeeping to update the new ancestor scores of descendants of those transactions (to reflect only the ancestors that are not yet selected), but because we can’t modify the mempool when constructing blocks, we still look at each transaction in the same order it appears in the mempool.
So if the mempool were to sort a child transaction based on an ancestor feerate that is higher than its own feerate, you might expect that it has some higher feerate parent that would be selected first, and therefore the child’s ancestor feerate would overstate its true mining score. This in turn would mean that we might look at many more transactions from the mempool than should be necessary when constructing a block, because those children would appear earlier in the mempool’s sort, so we’d look at them only to decide that the true feerate is lower than indicated. Instead, we try to
avoid this scenario by sorting transactions based on the minimum of the two feerates.
The implementation details are somewhat more involved than I described; see https://github.com/bitcoin/bitcoin/blob/d80348ccb65601d19b4b408d442e0999b5a6cf98/src/node/miner.cpp#L292C1-L429 for the full mining logic.
