<p>For miners lower transaction fee doesn't matters but fee rate does.
There are three cases where the miner chooses transactions with low fee rates.</p>

<p><strong>1)</strong> When the mempool has three sets of transactions <code>{A}:High fee rate</code> , <code>{B}:Average fee rate</code> and <code>{C}:Low fee rate</code>. If there are few transactions of set A and B the miner will select transactions from C as well.</p>

<p><strong>2)</strong> In a child-pay-for-parent scenario, where <code>A</code> is the parent transaction and <code>B</code> is the child transaction.</p>

<pre><code>A: { size: 200 vB, fee: 200 satoshi } ⇒ fee rate: 1 sats/vB
B: { size: 100 vB, fee: 2800 satoshi } ⇒ fee rate: 28 sats/vB
</code></pre>

<p>The miner really wants to collect the fee of B, but B spends an output of A, and the miner has to add both A and B in order to get the transaction fee.
You can see this in full detail <a href="https://bitcoin.stackexchange.com/questions/96447/does-descendant-size-effect-transaction-fee/96473#96473">here</a>.</p>

<p><strong>3)</strong> The miner has some personal interest to add a certain lower fee rate transaction.</p>

<p>Hope it helps.</p>

CC BY-SA 4.0
2020-06-14T11:00:20.833Z
2020-06-14T22:52:01.720Z
2020-06-14T22:52:01.720Z
Haseeb Saeed
<p>I assume the worst-case scenario, wherein the mempool there are many high fee tx and many low tx to choose from. Low fee tx may take a longer time to confirm. Miners don't have to worry that this tx gets included in other miners' block. This may give a slower miner some advantages in terms of mining. The miner may have taken some extra time to pre-calculate a bunch of Merkel root ready for hashing.  However, this is just theoretical. More studies may be required to verify this.</p>

CC BY-SA 4.0
2020-05-27T07:21:37.737Z
Interesting theory!
Nima
CC BY-SA 4.0
2020-06-14T22:02:15.737Z
-1 Calculating Merkle roots is not a bottleneck for miners, and using lower fee rate transactions gives them no advantage.
Murch
CC BY-SA 4.0
2021-08-15T02:33:48.517Z
I don;t understand why it does not give them any advantages?
Cisco Mmu
CC BY-SA 4.0
2020-05-26T06:58:34.713Z
2020-05-26T06:58:34.713Z
Cisco Mmu
<p>You are right, generally miners will pick the transactions with the highest fee rate first, so including low fee rate transactions while there are others with higher fee rate available seems irrational at first glance.</p>

<p>There are generally two reasons this comes to pass:</p>

<ol>
<li><strong>The miner has an out-of-band motivation to include the transaction.</strong><br>
For example, they are involved as sender or recipient in the
transaction, or are "accelerating" the transaction as a favor or in
exchange for an out-of-band payment.</li>
<li><strong>The transaction is part of a transaction chain/group with a sufficiently attractive fee rate.</strong><br>
Transactions consume existing unspent transaction outputs (UTXO) in their inputs, and create new transaction outputs. A transaction that spends a non-existent UTXO is invalid. Therefore, the transaction that creates an output must always precede the transaction that spends the same output. The "child-pays-for-parent" mechanism makes use of this dependency to reprioritize stuck transactions. To that end, an output of the stuck transaction is spent in a "child transaction" with a juicy fee. While previously the parent had a low priority, this new attractive child transaction cannot be included in a block before the parent is included. Both parent and child now queue as a unit at the effective fee rate of <code>Σ(fees)/Σ(sizes)</code>. To identify this scenario, you can look for chains of transactions in a single block where later transactions have higher fee rates.</li>
</ol>

CC BY-SA 4.0
2020-06-14T22:42:48.630Z
2020-06-14T23:00:29.113Z
2020-06-14T23:00:29.113Z
Murch
<p>Miners prefer high fee rate transactions to low fee rate ones, but the part which I don't understand is why miners pick a low fee rate transaction that has been waiting for hours in the mempool into their blocks, while they can find higher fee rate transactions in the mempool.
Is this some kind of moral thing to help those transactions to get confirmed or what?</p>

CC BY-SA 4.0
2020-06-14T22:07:49.300Z
Since you were specifically asking about "in terms of sat/byte" I have edited your question to use the term "fee rate" instead of "fee".
Murch
<transaction-fees><mining-reward><transaction-selection><blockspace-market>
Why do miners choose low fee rate transactions sometimes?
Nima
# Why do miners choose low fee rate transactions sometimes?

(Asked by: username_0 on 2020-05-24)

Miners prefer high fee rate transactions to low fee rate ones, but the part which I don't understand is why miners pick a low fee rate transaction that has been waiting for hours in the mempool into their blocks, while they can find higher fee rate transactions in the mempool.
Is this some kind of moral thing to help those transactions to get confirmed or what?

**Tags:** transaction-fees, mining-reward, transaction-selection, blockspace-market

> **Comments:**
> **username_1**: Since you were specifically asking about "in terms of sat/byte" I have edited your question to use the term "fee rate" instead of "fee".  

---

## 3 answers

### Answer by username_2 on 2020-06-14. Score: 2

For miners lower transaction fee doesn't matters but fee rate does.
There are three cases where the miner chooses transactions with low fee rates.

**1)** When the mempool has three sets of transactions `{A}:High fee rate` , `{B}:Average fee rate` and `{C}:Low fee rate`. If there are few transactions of set A and B the miner will select transactions from C as well.

**2)** In a child-pay-for-parent scenario, where `A` is the parent transaction and `B` is the child transaction.

```
A: { size: 200 vB, fee: 200 satoshi } ⇒ fee rate: 1 sats/vB
B: { size: 100 vB, fee: 2800 satoshi } ⇒ fee rate: 28 sats/vB

```

The miner really wants to collect the fee of B, but B spends an output of A, and the miner has to add both A and B in order to get the transaction fee.
You can see this in full detail [here](https://bitcoin.stackexchange.com/questions/96447/does-descendant-size-effect-transaction-fee/96473#96473).

**3)** The miner has some personal interest to add a certain lower fee rate transaction.

Hope it helps.


---

### Answer by username_3 on 2020-05-26. Score: 1

I assume the worst-case scenario, wherein the mempool there are many high fee tx and many low tx to choose from. Low fee tx may take a longer time to confirm. Miners don't have to worry that this tx gets included in other miners' block. This may give a slower miner some advantages in terms of mining. The miner may have taken some extra time to pre-calculate a bunch of Merkel root ready for hashing. However, this is just theoretical. More studies may be required to verify this.

> **Comments:**
> **username_0**: Interesting theory!  
> **username_1**: -1 Calculating Merkle roots is not a bottleneck for miners, and using lower fee rate transactions gives them no advantage.  
> **username_3**: I don;t understand why it does not give them any advantages?  

---

### Answer by username_1 on 2020-06-14. Score: 0

You are right, generally miners will pick the transactions with the highest fee rate first, so including low fee rate transactions while there are others with higher fee rate available seems irrational at first glance.

There are generally two reasons this comes to pass:

1. **The miner has an out-of-band motivation to include the transaction.**  
   For example, they are involved as sender or recipient in the
   transaction, or are "accelerating" the transaction as a favor or in
   exchange for an out-of-band payment.
2. **The transaction is part of a transaction chain/group with a sufficiently attractive fee rate.**  
   Transactions consume existing unspent transaction outputs (UTXO) in their inputs, and create new transaction outputs. A transaction that spends a non-existent UTXO is invalid. Therefore, the transaction that creates an output must always precede the transaction that spends the same output. The "child-pays-for-parent" mechanism makes use of this dependency to reprioritize stuck transactions. To that end, an output of the stuck transaction is spent in a "child transaction" with a juicy fee. While previously the parent had a low priority, this new attractive child transaction cannot be included in a block before the parent is included. Both parent and child now queue as a unit at the effective fee rate of `Σ(fees)/Σ(sizes)`. To identify this scenario, you can look for chains of transactions in a single block where later transactions have higher fee rates.


---

