I send all the btc in one wallet to another wallet of my own, so as i didn´t have a rush i put a small fee, too low to be honest. I´ve read that eventually the transaction will be forgoten and returned to original wallet, but I also read about transaction being stuck for months. Anyone can help me or give more information about it? Can anybody tell me certainly how much time take to a transaction to be forgoten? Thanks a lot..
-
Do you know what you had your fee set at? How many satoshis per byte was your transaction? Depending what your fee was set at it might just take some time before it goes through.– m1xolyd1anCommented May 19, 2020 at 14:17
-
3Does this answer your question? Why is my transaction not getting confirmed and what can I do about it?– MCCCSCommented May 19, 2020 at 15:34
2 Answers
I send all the btc in one wallet to another wallet of my own, so as i didn´t have a rush i put a small fee, too low to be honest.
That's a known problem : when mempool median feerate spikes after you broadcast your transaction, or in your case doesn't lower as you may have expected.
That's the reason why marking transactions as replaceable is useful in the first place: if a transaction gets stuck, it enables you to replace the already broadcast transaction with a new one paying more fees. This is not permitted for transactions that do not signal replaceability.
What wallet did you use ? Most wallets today offer the possibility to signal for RBF (*), and you may just be able to replace your low-feerate transaction.
Can anybody tell me certainly how much time take to a transaction to be forgoten?
The default for nodes on the network is set to 336 hours (bitcoind
's -mempoolexpiry
option).
EDIT : As @Murch pointed out in the comments, you can also try CPFP on the receiver side, i.e. spend the unconfirmed transaction with a high-fee transaction to bump the overall feerate of the "package" (we call "package" the unconfirmed transaction chain).
(*) Was grossly "most wallet signal RBF" before EDIT, which is wrong and reflected by the mempool (corrected by @Murch, thanks!).