From what I understand, a low fee transaction should drop out of mempools at some point when it gets purged. However, with so many different mempools out there, will this realistically ever happen? For example, I've had a test transaction unconfirmed for 2 months, my own node's mempool dropped it after a month, but many others did not, so it was still floating out there and now it got confirmed during the lower volume time.
Has anyone ever had a transaction to drop out of all mempools? I am a bit doubtful that this can happen.
You should always assume that it never drops from all mempools. Because someone could be a sneaky bastard and store it and release it to the mempool again at any point later in time.
If your transactions gets stuck, either increase the effective fee to make it puah through, or send the affected UTXOs to yourself through another transaction to make the first one invalid.
reply
You should always assume that it never drops from all mempools. Because someone could be a sneaky bastard and store it and release it to the mempool again at any point later in time.
That is what I always assume too. Also, for example mempool.space has this in their FAQ:
mempool.space uses multiple Bitcoin nodes to obtain data: some with the default 300MB mempool memory limit (call these Small Nodes) and others with a much larger mempool memory limit (call these Big Nodes).
Many nodes on the Bitcoin network are configured to run with the default 300MB mempool memory setting. When all 300MB of memory are used up, such nodes will reject transactions below a certain threshold feerate. Running Small Nodes allows mempool.space to tell you what this threshold feerate is—this is the "Purging" feerate that shows on the front page when mempools are full, which you can use to be reasonably sure that your transaction will be widely propagated.
Big Node mempools are so big that they don't need to reject (or purge) transactions. Such nodes allow for mempool.space to provide you with information on any pending transaction it has received—no matter how congested the mempool is, and no matter how low-feerate or low-priority the transaction is.
So basically, no transaction ever leaves the big node :).
reply
Yeah, but Bitcoin Core nodes only relay each transaction once to their peers when they first learn about it. Nodes do not rebroadcast foreign transactions, even when they may have transactions that other nodes have already forgotten about.
reply
Interesting. Thanks for sharing this info.
Wouldn't this mean though that if the tx is at least in one mempool which does not drop it, then it is still alive, ready to be mined?
reply
Exactly.
reply
Yes, any valid Bitcoin transaction that has been broadcast to the network stays valid indefinitely, unless a conflicting transaction that spends some of the same inputs is mined into a block. That means even if most nodes forget about transactions, you cannot rely on the default behavior of nodes (i.e. the two week timeout and the not rebroadcasting), you need to expect that any transaction you have ever submitted to the network might still get mined, unless it has been replaced. Optimally if you repeat a payment in a new transaction because the old got stuck and eventually dropped, you should use one of the same inputs in the replacement transaction: that way the two attempts at paying the recipient are exclusive, only one can get into the blockchain. Alternatively, you might just want to explicitly spend one of the inputs as soon as you get around to it after a transaction is dropped from the mempool, unless you’re still trying to get it confirmed.
reply
The longest I have had a transaction sit in mempools is a few weeks. Dropped out of my node's but was confirmed.
reply
Try to send the same UTXO again with a higher fee. If it works it means you wallet/node has dropped it from the mempool.
I've found some wallets keep it for months while others will drop it after a few weeks or so.
reply
I had a similar situation.
It took about 19 days to complete.
reply
I would like also to hear this from anyone who actually experienced.
reply