<p>Yes, this is an accurate description of the mempool behaviour. When a transaction is expired from the mempool, its descendants are as well.</p>
<p>When <code>txA</code> gets dropped, so does <code>txB</code>. If we later re-broadcast <code>txB</code> (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 <code>txA</code> in the next 20 minutes (timeout for orphan tx cache eviction), and it passes policy checks <strong>on its own</strong> <code>txA</code> would be added back to the mempool.<br />
Note that the peers would only request it if we send them an <code>inv</code> for <code>txA</code>.</p>
<p>However, there are no such thing as &quot;propagation as a unit&quot; on the P2P network currently (package relay design <a href="https://github.com/bitcoin/bitcoin/issues/14895" rel="nofollow noreferrer">is being discussed here</a>). This is the reason why in your example <code>txA</code> must pass the policy checks on its own.<br />
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 <code>txA</code> which happens to be below most of the network mempool minimum feerate at the time of broadcast <em>won't be accepted even with a high fee-paying <code>txB</code></em> (1)(2).</p>
<hr />
<p>(1) This is the reason why the Lightning protocol kept the <code>update_fee</code> message even post <a href="https://github.com/lightningnetwork/lightning-rfc/pull/688" rel="nofollow noreferrer">anchor outputs</a>.<br />
(2) This has implication in other L2 protocols too. For example in Revault it <a href="https://github.com/re-vault/practical-revault/issues/15" rel="nofollow noreferrer">could prevent one to unvault a vault</a> until the mempool backlog is processed.</p>

CC BY-SA 4.0
2020-12-31T13:25:48.483Z
2020-12-31T16:26:01.970Z
2020-12-31T16:26:01.970Z
Antoine Poinsot
<p>Such Transactions cannot be proceeded without output from their parents. Hence they are  also removed from the mempool</p>

CC BY-SA 4.0
2020-06-09T02:57:44.063Z
2020-06-09T02:57:44.063Z
Haseeb Saeed
<p>I was just reading the <a href="https://coinmetrics.substack.com/p/coin-metrics-state-of-the-network-9b9" rel="noreferrer">Coin Metrics Newsletter #53</a>, 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:</p>
<blockquote>
<p>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).</p>
<p>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 <strong>spent unconfirmed parent transactions and became invalid as their parents expired</strong>.</p>
</blockquote>
<p>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?</p>
<p>If yes, let's say <code>txA</code> was in the mempool for two weeks and got dropped, and <code>txB</code> was a CPFP transaction spending an output of <code>txA</code> which therefore got invalidated and dropped as well.</p>
<p>What would happen if the original sender rebroadcast <code>txB</code>? Given that <code>txB</code> inputs would appear to not exist without the context of <code>txA</code>, would the peers of the sender request the preceding transaction <code>txA</code> or just reject <code>txB</code>? Would then the two transactions repropagate as a unit?</p>

<unconfirmed-transactions><mempool><peers><transaction-propagation>
What happens to transactions in the mempool when their parent transaction expires?
Murch
# What happens to transactions in the mempool when their parent transaction expires?

(Asked by: username_0 on 2020-06-07)

I was just reading the [Coin Metrics Newsletter #53](https://coinmetrics.substack.com/p/coin-metrics-state-of-the-network-9b9), 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?

**Tags:** unconfirmed-transactions, mempool, peers, transaction-propagation


---

## 2 answers

### Answer by username_1 on 2020-12-31. Score: 2 | Accepted answer

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](https://github.com/bitcoin/bitcoin/issues/14895)). 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](https://github.com/lightningnetwork/lightning-rfc/pull/688).  
(2) This has implication in other L2 protocols too. For example in Revault it [could prevent one to unvault a vault](https://github.com/re-vault/practical-revault/issues/15) until the mempool backlog is processed.


---

### Answer by username_2 on 2020-06-09. Score: 1

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


---

