So, I've noticed that when a transaction sits in the mempool for too long without being picked up by miners, it gets dropped after about 48 days. Why doesn't it just get pushed to a miner instead? It's gonna be sent again anyway and eventually mined, right? Or is this just to help the sender not stress about their BTC sitting there?
Unmined Transactions in the Mempool
12 replies 318 views
SwiftMatr1xFull Member
Posts: 59 · Reputation: 474
#2Apr 5, 2025, 11:00 AM
A pending transaction is not sent back, it never even left the sending wallet at any point.
For the transaction to be cancelled it has to be dropped from the mempool of majority of nodes for the transaction making it unavailable for miners to add to their blocks.
The default time for this to happen is 14 days, but can always be higher or lower depending on the nodes specifications.
Note that the transaction can be rebroadcasted at any point during this time.
There is no definiteness that a transaction will be confirmed. The sender needs to bump the fee most of the times before the transaction can be confirmed.
- Jay -
The default minimum time for transaction to been sent back to the sender address or Wallet is 14 days which also varies because of some factors like the wallet having in an in built rebroadcast feature or base one the Time each node picks the transaction into their individual pool.
The resending will depend on the fee, if the miner drops it and probably other miners have it and later the fee gets lower or mempool gets less congested then the miner will pick it again. Not that it is a default thing that he will re pick it again.
Use a wallet with transaction fee bumping features so that when this things happen you bump your transaction fee.
If the fee rate that is getting transactions confirmed at the time is not used, and if the mempool did not become decongested to the fee rate or below the fee rate the sender used, do not expect miners to pickup the transaction.
The default time for mempool to drop an unconfirmed transaction is 14 days. Be expecting the transaction to have been dropped from mempool after 14 days.
Technically the said transaction has to be dropped from the mempool of all nodes not just a portion of them because even if it is only one node out there that stores this transaction, it can continue broadcasting it until it is either confirmed or becomes invalid (eg. double spent).
QuantumYieldSenior Member
Posts: 117 · Reputation: 813
#6Apr 6, 2025, 04:28 PM
There are many mempools and each mempool has its own settings. The common setting by many mempools result in drop of too low fee rate pending transactions but as pooya87 wrote, not all mempools are the same and if only one mempool does not drop your pending transaction, it can be confirmed.
Memory pool.
Bitcoin Core Config Generator (Jameson Lopp). It uses a default value (300) too.
The transaction from the network will be dropped in 14 days not 48 as far as I know, other possible factors due to very low fee that is below the purging level, and once every node drops then it will be dropped from the network even before 14 days or the network may stay forever if your wallet keeps rebroadcasting the transaction with the same fee which is not enough to get into a block but above the minimum fee.
Miners always prioritize the TX with higher fees to maximize their revenue so this restricts the TX with low fee stays in the network in the queue of unconfirmed TX. It doesn't seem logical to pick the TXs with lowers fees by miners unless they really want to. So the only way to make possible your proposal is to set up a pool and only include the TX with a low fee.
The TX status will remain the same as long as they are sent with the same fee so it's the responsibility of the sender to increase the TX fee if they want their TX to get confirmed faster.
They can increase the fee using Replace-By-Fee (RBF) or Child-Pays-For-Parent (CPFP) even if they transacted with a low fee accidentally.
just_wizardFull Member
Posts: 85 · Reputation: 583
#8Apr 8, 2025, 04:32 AM
I'll share my experience her so you understand how wallets and nodes work.
Few weeks ago (more than two weeks) I've made a transaction and broadcast it with 1 sat/vb for testing purposes. It has been broadcast but few minutes later it has been rejected and my Electrum wallet showed it as local, so I've deleted it.
Yesterday, I opened my wallet and was surprised to see the transaction is still there and waiting for confirmation. The first time I saw it, I thought my wallet was compromised and some one was trying to steal my money till I remembered it was me who've created this transaction.
I thought it has been rejected by all nodes and I'll never see it again, well, I was wrong 😅
This oddity is probably because your client changed server behind the scene (automatic server selection must be on) which means in first attempt you sent the transaction to a node with a bigger mempool size which accepted it and kept it in its mempool. Then your client changed server and tried syncing with the other one that had a smaller mempool size which meant it rejected the low paying tx turning it into local.
The next time you opened Electrum you again connected to a node with bigger mempool that had your old tx hence showing it as pending!
So far, as I understood, you mean that when you send transaction with low fee that is not enough to get confirmation, transaction is stuck in mempool for 48 days and then gets cancelled and your question is, why doesn't it gets rebroadcasted again automatically with the hope of getting confirmation in near future? Am I right?
Okay, it has more pros than cons. If you send transaction without enabling RBF and can't do CPFP, then you will be able to get your coins back when nodes forget your transaction and you'll be able to resend them. Otherwise, if it was rebroadcasted frequently, then your transaction could probably be stuck for months and even more or forever if fees are going to remain permanently higher than what you paid. But there we have FULL RBF feature that will give everyone possibility to increase their transaction fee and get rid of waiting for confirmations forever.
So you are saying mempool have sizes and they are different from each other or this is determined by the node you're broadcasting on.
diamond365Full Member
Posts: 136 · Reputation: 744
#12Apr 8, 2025, 08:10 PM
Each mempool can set different memory pool and they can set their max mempool size, mempool expiration.
Like this
https://jlopp.github.io/bitcoin-core-config-generator/
This example setting has max mempool size is 500 megabytes, mempool expiration (hours) is 336 = 14 days.
mempoolexpiry=336 (hours)
mempoolminfee =0.00001000
mempoolminfee is used to set min fee rate and transactions with lower fee rate than this will be dropped from a mempool but it can be kept in other mempools that have min fee rate is lower than this.
https://chainquery.com/bitcoin-cli/getmempoolinfo
Yes. Certain settings are a matter of preference that can be set by the node operator, such as the size of the mempool or even what transactions you accept in your mempool. For example the node I run is set to reject the spam attacks like the Ordinals Attack transactions.
?Reply
Sign in to reply to this topic
Related topics
- Electrum Fees for Transactions 13
- bitcoin-qt sync issues and slow speeds 6
- Recovering a Bitcoin wallet and address 8
- Creating a list of non-zero wallets and their balances using Python 4
- CipherSeed: A Comprehensive Guide to Super-Secure Crypto Wallet Backups 5
- Curious about recovering BTC from 2010/2011 7