<p>By default Bitcoin Core’s mempool data structure is limited to using no more than 300 MiB of RAM. If your node has been consistently online, it would currently be full of transactions that pay about 4.6 s/vB or more. It seems to me that the transaction you were trying to send paid less than your own mempool’s minimum feerate and thus was rejected with the reason &quot;insufficient fee&quot;.</p>

CC BY-SA 4.0
2024-02-20T18:57:06.517Z
Is there a way to estimate the current "mempool's feerate" ? I thought it was 1s/vB. If the answer is yes, would that mean that the minimum ferrate is dynamic and depends on the state of the mempool?
Nahum Maurice
CC BY-SA 4.0
2024-02-20T21:34:13.593Z
I conducted such experiment: After one successful tx, I multiplied the fee by 5 and it works. In order for it to work on the 3rd time, I had to multiply the same fee by 10. Otherwise, I got the same error. I'm not sure I understand why since `getmempoolinfo` got me `mempoolminfee` and `minrelaytxfee` to be equal to 1e-05.
Nahum Maurice
CC BY-SA 4.0
2024-02-20T21:53:12.923Z
Is it possible that it was 10e5, instead of 10e-5? Otherwise, this related topic might be of interest: https://bitcoin.stackexchange.com/q/96068/5406
Murch
CC BY-SA 4.0
2024-02-21T07:22:51.250Z
1e-5 BTC/kvb is 1sat/vb so seems plausible, especially if the node was recently restarted. (If the tx pays to bare multisig outputs, it could have a high sigop count leading to a lower effective feerate than you'd get by just looking at the tx size and fee directly)
Anthony Towns
CC BY-SA 4.0
2024-02-20T18:14:07.160Z
2024-02-20T18:14:07.160Z
Murch
<p>I'm using Bitcoin Core, and for some reason, it doesn't want to accept transactions when I already have other transactions in the mempool, even if those transactions are using different UTxOs and they have different non-witness data. I have enough to pay for the transaction and fees. I also make sure that the fees are greater than the vsize which means that the problem is not with the fee.</p>
<p>Can someone provide an insight about this specific reject-reason?</p>

<bitcoin-core><bitcoind><transaction-fees><bitcoin-cli><mempool>
Mempool not accepting transactions: 'reject-reason': 'insufficient fee'
Nahum Maurice
# Mempool not accepting transactions: 'reject-reason': 'insufficient fee'

(Asked by: username_0 on 2024-02-20)

I'm using Bitcoin Core, and for some reason, it doesn't want to accept transactions when I already have other transactions in the mempool, even if those transactions are using different UTxOs and they have different non-witness data. I have enough to pay for the transaction and fees. I also make sure that the fees are greater than the vsize which means that the problem is not with the fee.

Can someone provide an insight about this specific reject-reason?

**Tags:** bitcoin-core, bitcoind, transaction-fees, bitcoin-cli, mempool


---

## 1 answers

### Answer by username_1 on 2024-02-20. Score: 0

By default Bitcoin Core’s mempool data structure is limited to using no more than 300 MiB of RAM. If your node has been consistently online, it would currently be full of transactions that pay about 4.6 s/vB or more. It seems to me that the transaction you were trying to send paid less than your own mempool’s minimum feerate and thus was rejected with the reason "insufficient fee".

> **Comments:**
> **username_0**: Is there a way to estimate the current "mempool's feerate" ? I thought it was 1s/vB. If the answer is yes, would that mean that the minimum ferrate is dynamic and depends on the state of the mempool?  
> **username_0**: I conducted such experiment: After one successful tx, I multiplied the fee by 5 and it works. In order for it to work on the 3rd time, I had to multiply the same fee by 10. Otherwise, I got the same error. I'm not sure I understand why since `getmempoolinfo` got me `mempoolminfee` and `minrelaytxfee` to be equal to 1e-05.  
> **username_1**: Is it possible that it was 10e5, instead of 10e-5? Otherwise, this related topic might be of interest: https://bitcoin.stackexchange.com/q/96068/5406  
> **username_2**: 1e-5 BTC/kvb is 1sat/vb so seems plausible, especially if the node was recently restarted. (If the tx pays to bare multisig outputs, it could have a high sigop count leading to a lower effective feerate than you'd get by just looking at the tx size and fee directly)  

---

