Why do miners choose low fee rate transactions sometimes?

Question

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?

Answer 1

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.

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

Hope it helps.

Answer 2

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.

Answer 3

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.