What happens to transactions in the mempool when their parent transaction expires?

Question

I was just reading the Coin Metrics Newsletter #53, and it included a section about the recent mempool congestion. After mentioning transactions that got evicted due to the network's queue of unconfirmed transactions exceeding the default mempool limit, it mentions about transactions expiring due to the 14 day limit:

Secondly, transactions residing in the mempool for over two weeks expired. By default, Bitcoin Core nodes remove transactions from their mempool if no miner found transaction fees to be attractive enough to include them in a block over the last 336 hours (two weeks).

In total 1,627 transactions expired between May 25th, and May 30th. Only 35% of these resided in the mempool for two weeks. The remaining 65% likely spent unconfirmed parent transactions and became invalid as their parents expired.

In the last sentence (highlight added), the newsletter describes that transactions chained from expired transactions would get dropped from the mempool as well. Is that an accurate description of the mempool behavior?

If yes, let's say txA was in the mempool for two weeks and got dropped, and txB was a CPFP transaction spending an output of txA which therefore got invalidated and dropped as well.

What would happen if the original sender rebroadcast txB? Given that txB inputs would appear to not exist without the context of txA, would the peers of the sender request the preceding transaction txA or just reject txB? Would then the two transactions repropagate as a unit?

Answer 1

Yes, this is an accurate description of the mempool behaviour. When a transaction is expired from the mempool, its descendants are as well.

When txA gets dropped, so does txB. If we later re-broadcast txB (and it's not too large) our peers will add it to a (small) cache of orphaned transaction they keep for us. If we broadcast txA in the next 20 minutes (timeout for orphan tx cache eviction), and it passes policy checks on its own txA would be added back to the mempool.
Note that the peers would only request it if we send them an inv for txA.

However, there are no such thing as "propagation as a unit" on the P2P network currently (package relay design is being discussed here). This is the reason why in your example txA must pass the policy checks on its own.
This has implications on L2 protocols with pre-signed transactions, for example in the Lightning Network where the transaction relay is critical. A pre-signed txA which happens to be below most of the network mempool minimum feerate at the time of broadcast won't be accepted even with a high fee-paying txB (1)(2).

---

(1) This is the reason why the Lightning protocol kept the update_fee message even post anchor outputs.
(2) This has implication in other L2 protocols too. For example in Revault it could prevent one to unvault a vault until the mempool backlog is processed.

Answer 2

Such Transactions cannot be proceeded without output from their parents. Hence they are also removed from the mempool