<p>Miners are not obligated to include transactions that are in the mempool - there would be no way to enforce this. As long as the transactions are valid, a miner can include whatever transactions they want. These can be at any feerate, do non-standard things, exceed mempool policy limits, etc.</p>
<p>The miner of this block could have just received the transactions out of band and included them in their block.</p>

CC BY-SA 4.0
2023-10-11T21:21:32.857Z
I understand, but these transactions also appeared on my node's `getblocktemplate` command. How is this possible, if my node is purging fee rates lower than what they have?

Is it more complex than a simple `if (fee_rate < min_fee_rate) then purge`?

Note, the images above are _not_ of mined blocks, but the template of the next block .
Steven
CC BY-SA 4.0
2023-10-11T21:56:11.580Z
Oh, I see. Yes, eviction is more complicated than just that. It looks at descendant set feerate.
Ava Chow
CC BY-SA 4.0
2023-10-11T22:05:02.013Z
Makes sense. What's strange is that it those transactions didn't have any descendants (not CPFP'd). It's effective fee rate was 1.49sats/vb. However, these were large consolidation transactions, so I wonder if absolute fee / tx size plays a role?
Steven
CC BY-SA 4.0
2023-10-11T21:05:41.447Z
2023-10-11T21:05:41.447Z
Ava Chow
<p>2 possible explanations for this:</p>
<p>(1) The mempool min feerate is set at 1 sat/vB (<code>-incrementalRelayFee</code>) <em>above</em> the highest score of transaction(s) evicted (this is anti-DoS / saves work; you shouldn't be able to re-submit what you just purged). See next point for &quot;score,&quot; but in the case of independent transactions, it's just their feerate. If the lowest-score transactions in your mempool are 1.1 sat/vB, 1.2 sat/vB, 1.5 sat/vB, etc, evicting just the lowest score transaction would bump the minimum feerate to 2.1 sat/vB and you’d have plenty of transactions sitting below that. Based on what you're describing and the pink-ness of that mempool.space screenshot, a large volume of consolidation transactions sitting between 1 and 2sat/vB makes this explanation quite likely.</p>
<p>(2) Selection is by ancestor set scoring and eviction is by descendant set scoring. It’s possible for a transaction to have a low ancestor score but a high descendant score and vice versa. A very good example is illustrated in <a href="https://github.com/bitcoin/bitcoin/issues/27677" rel="nofollow noreferrer">this issue</a> (which also describes a proposal to change this fact).</p>

CC BY-SA 4.0
2023-10-12T19:29:29.330Z
If you run your node with default values, it should never have a transaction that pays less than `minRelayTxFeerate` (1 sat/vB). So if a transaction with minRelayTxFeerate gets evicted, wouldn’t your explanation mean that the purge feerate would directly jump to at least (2 sat/vB)? How would it then ever be able to get to 1.51? :thinking-face:
Murch
CC BY-SA 4.0
2023-10-12T20:27:36.733Z
> How would it then ever be able to get to 1.51? :thinking-face:

The dynamic mempool min feerate decays downwards as blocks are mined and the mempool starts emptying again. This decay is gradual, so it can be 1.51 on the way down.
glozow
CC BY-SA 4.0
2023-10-12T21:10:47.263Z
> "If the lowest-score transactions in your mempool are 1.1sat/vb, 1.2sat/vb, 1.5sat/vB, etc, evicting just the lowest score tx would bump the minimum feerate to 2.1sat/vb and you’d have plenty of transactions sitting below that."



So the 1.2sat/vb, 1.5.sat/vb transactions in your example would remain in the mempool, despite the new minimum fee rate being 2.1sat/vb?
Steven
CC BY-SA 4.0
2023-10-13T07:58:46.777Z
Yes. There's no need to keep evicting after you're back within `-maxmempool`.
glozow
CC BY-SA 4.0
2023-10-12T07:41:52.817Z
2023-10-25T19:00:21.093Z
2023-10-25T19:00:21.093Z
glozow
<p>Over the weekend, the Bitcoin mempool size exceeded the default 300mb limit and was purging transactions. Most transactions in the mempool consisted of these large batches/consolidations at ~1.5sat/vb.</p>
<p>What was strange was that the min mempool fee rate for my default node was <em>higher</em> than some of these transactions that were in the next block template.</p>
<p>It didn't look like these transactions were CPFP'd either. Attached are some screenshots of mempool.space illustrating this.</p>
<p><strong>Default mempool purging txs at 1.51sat/vb</strong>
<a href="https://i.sstatic.net/LX4W3l.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/LX4W3l.png" alt="enter image description here" /></a></p>
<p><strong>Next block template having transactions with 1.49sat/vb</strong><br />
(note there is no &quot;effective fee rate&quot; which is added to txs that are CPFP'd):</p>
<p><a href="https://i.sstatic.net/QG9mSl.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/QG9mSl.png" alt="enter image description here" /></a></p>

<transaction-fees><mempool>
How can the next block fee be less than the mempool purging fee rate?
Steven
# How can the next block fee be less than the mempool purging fee rate?

(Asked by: username_0 on 2023-10-11)

Over the weekend, the Bitcoin mempool size exceeded the default 300mb limit and was purging transactions. Most transactions in the mempool consisted of these large batches/consolidations at ~1.5sat/vb.

What was strange was that the min mempool fee rate for my default node was *higher* than some of these transactions that were in the next block template.

It didn't look like these transactions were CPFP'd either. Attached are some screenshots of mempool.space illustrating this.

**Default mempool purging txs at 1.51sat/vb**
[![enter image description here](https://i.sstatic.net/LX4W3l.png)](https://i.sstatic.net/LX4W3l.png)

**Next block template having transactions with 1.49sat/vb**  
(note there is no "effective fee rate" which is added to txs that are CPFP'd):

[![enter image description here](https://i.sstatic.net/QG9mSl.png)](https://i.sstatic.net/QG9mSl.png)

**Tags:** transaction-fees, mempool


---

## 2 answers

### Answer by username_2 on 2023-10-12. Score: 8 | Accepted answer

2 possible explanations for this:

(1) The mempool min feerate is set at 1 sat/vB (`-incrementalRelayFee`) *above* the highest score of transaction(s) evicted (this is anti-DoS / saves work; you shouldn't be able to re-submit what you just purged). See next point for "score," but in the case of independent transactions, it's just their feerate. If the lowest-score transactions in your mempool are 1.1 sat/vB, 1.2 sat/vB, 1.5 sat/vB, etc, evicting just the lowest score transaction would bump the minimum feerate to 2.1 sat/vB and you’d have plenty of transactions sitting below that. Based on what you're describing and the pink-ness of that mempool.space screenshot, a large volume of consolidation transactions sitting between 1 and 2sat/vB makes this explanation quite likely.

(2) Selection is by ancestor set scoring and eviction is by descendant set scoring. It’s possible for a transaction to have a low ancestor score but a high descendant score and vice versa. A very good example is illustrated in [this issue](https://github.com/bitcoin/bitcoin/issues/27677) (which also describes a proposal to change this fact).

> **Comments:**
> **username_3**: If you run your node with default values, it should never have a transaction that pays less than `minRelayTxFeerate` (1 sat/vB). So if a transaction with minRelayTxFeerate gets evicted, wouldn’t your explanation mean that the purge feerate would directly jump to at least (2 sat/vB)? How would it then ever be able to get to 1.51? :thinking-face:  
> **username_2**: > How would it then ever be able to get to 1.51? :thinking-face:  The dynamic mempool min feerate decays downwards as blocks are mined and the mempool starts emptying again. This decay is gradual, so it can be 1.51 on the way down.  
> **username_0**: > "If the lowest-score transactions in your mempool are 1.1sat/vb, 1.2sat/vb, 1.5sat/vB, etc, evicting just the lowest score tx would bump the minimum feerate to 2.1sat/vb and you’d have plenty of transactions sitting below that."    So the 1.2sat/vb, 1.5.sat/vb transactions in your example would remain in the mempool, despite the new minimum fee rate being 2.1sat/vb?  
> **username_2**: Yes. There's no need to keep evicting after you're back within `-maxmempool`.  

---

### Answer by username_1 on 2023-10-11. Score: 4

Miners are not obligated to include transactions that are in the mempool - there would be no way to enforce this. As long as the transactions are valid, a miner can include whatever transactions they want. These can be at any feerate, do non-standard things, exceed mempool policy limits, etc.

The miner of this block could have just received the transactions out of band and included them in their block.

> **Comments:**
> **username_0**: I understand, but these transactions also appeared on my node's `getblocktemplate` command. How is this possible, if my node is purging fee rates lower than what they have?  Is it more complex than a simple `if (fee_rate < min_fee_rate) then purge`?  Note, the images above are _not_ of mined blocks, but the template of the next block .  
> **username_1**: Oh, I see. Yes, eviction is more complicated than just that. It looks at descendant set feerate.  
> **username_0**: Makes sense. What's strange is that it those transactions didn't have any descendants (not CPFP'd). It's effective fee rate was 1.49sats/vb. However, these were large consolidation transactions, so I wonder if absolute fee / tx size plays a role?  

---

