<p>Your funds are not lost. If the transaction does not get confirmed, the funds are still held by the previous transaction outputs and are available to be spent in a new transaction. If the transaction gets confirmed, the funds will be held by the new output that you intended to pay to in the first place.</p>
<p>The transaction <a href="https://mempool.space/tx/ce75cb0a602fe6089c6c944ebe555d413d55b2ec4df1489cc4275f4cde6f6eb4" rel="nofollow noreferrer">ce75cb…6f6eb4</a> actually did signal replaceability. I would guess that you sent all funds from the original wallet and therefore an attempt to rbf-bump the transaction failed because there were neither a change output nor  additional funds to increase the feerate. The wallet doesn’t know that you’re trying to send to yourself, so it wouldn’t automatically reduce the recipient amount to increase the fees.</p>
<p>You could try to:</p>
<ul>
<li>use child-pays-for-parent from the receiver wallet to reprioritize this transaction</li>
<li>manually “abandon” the old transaction on the old wallet and create a new transaction with a higher feerate that uses at least one of the same inputs to create a conflict and supersede the original transaction. Since the current mempool conditions are such that most nodes have evicted all transactions with feerates below 3 ṩ/vB, your new transaction would easily propagate even if it had not signaled RBF.</li>
</ul>
<p>Please check out <a href="https://bitcoin.stackexchange.com/q/9046/5406">Why is my transaction not getting confirmed and what can I do about it?</a> for more information.</p>

CC BY-SA 4.0
2023-05-05T13:47:02.860Z
2023-05-05T13:47:02.860Z
Murch
<blockquote>
<p>Is there a possibility of losing the transmitted value?</p>
</blockquote>
<p>No</p>
<blockquote>
<p>Or, about how long, in your opinion, it has to stay in the mempool,</p>
</blockquote>
<p>Each node independently decides how long they keep transactions in their mempool</p>
<blockquote>
<p>until it is confirmed.</p>
</blockquote>
<p>Or until too old</p>
<blockquote>
<p>Is it possible that it will never be confirmed?</p>
</blockquote>
<p>Yes, but the network will accept a later transaction spending the same inputs at a higher fee rate.</p>

CC BY-SA 4.0
2023-05-05T10:22:59.607Z
Thanks for answers. I am confusing a little bit. I understand  that sooner or later, somehow, the transaction will be accepted with this low fee, by a miner/node. I don't realize what means too old in mempool. Anyway obviously I can't initialize send another transaction with the necessary fee to be confirmed. As I say Replace-by-fee is not possible. All these aspects result in the loss of the transaction value. That I consider not wright and fair. In this case, the Bitcoin Core wallet should not allow transactions under any circumstances to avoid this kind of extremely embarrassing situations.
Ovidiu
CC BY-SA 4.0
2023-05-05T08:28:40.717Z
2023-05-05T08:28:40.717Z
RedGrittyBrick
<p>I use Bitcoin Core 22.0. I sent a transaction.
By mistake I chose a low feerate, and now the transaction is stuck in the mempool, and who knows if anyone will notice it. In previous versions of Bitcoin Core, when sending transactions, the wallet software calculated your transaction fee. Maybe that's why I went on trust and carried it out, as it was implied.
Now I can't change anything, obviously, even Replace-by-fee (RBF) is not activated. The transaction remains unconfirmed for more than 9 days (at least 220 hours)
Transaction details are here: <a href="https://explorer.btc.com/btc/transaction/ce75cb0a602fe6089c6c944ebe555d413d55b2ec4df1489cc4275f4cde6f6eb4" rel="nofollow noreferrer">https://explorer.btc.com/btc/transaction/ce75cb0a602fe6089c6c944ebe555d413d55b2ec4df1489cc4275f4cde6f6eb4</a>
Is there a possibility of losing the transmitted value? Or, about how long, in your opinion, it has to stay in the mempool, until it is confirmed. Is it possible that it will never be confirmed?
Thanks for patience and understanding.
Greets from Romania!</p>

CC BY-SA 4.0
2023-05-05T13:38:10.363Z
The transaction ce75cb0a602fe6089c6c944ebe555d413d55b2ec4df1489cc4275f4cde6f6eb4 did signal RBF.
Murch
<bitcoin-core><transaction-fees><unconfirmed-transactions><transaction-verification><mempool>
Unconfirmed transaction Bitcoin Core 22.0
Ovidiu
# Unconfirmed transaction Bitcoin Core 22.0

(Asked by: username_0 on 2023-05-05)

I use Bitcoin Core 22.0. I sent a transaction.
By mistake I chose a low feerate, and now the transaction is stuck in the mempool, and who knows if anyone will notice it. In previous versions of Bitcoin Core, when sending transactions, the wallet software calculated your transaction fee. Maybe that's why I went on trust and carried it out, as it was implied.
Now I can't change anything, obviously, even Replace-by-fee (RBF) is not activated. The transaction remains unconfirmed for more than 9 days (at least 220 hours)
Transaction details are here: <https://explorer.btc.com/btc/transaction/ce75cb0a602fe6089c6c944ebe555d413d55b2ec4df1489cc4275f4cde6f6eb4>
Is there a possibility of losing the transmitted value? Or, about how long, in your opinion, it has to stay in the mempool, until it is confirmed. Is it possible that it will never be confirmed?
Thanks for patience and understanding.
Greets from Romania!

**Tags:** bitcoin-core, transaction-fees, unconfirmed-transactions, transaction-verification, mempool

> **Comments:**
> **username_1**: The transaction ce75cb0a602fe6089c6c944ebe555d413d55b2ec4df1489cc4275f4cde6f6eb4 did signal RBF.  

---

## 2 answers

### Answer by username_1 on 2023-05-05. Score: 2

Your funds are not lost. If the transaction does not get confirmed, the funds are still held by the previous transaction outputs and are available to be spent in a new transaction. If the transaction gets confirmed, the funds will be held by the new output that you intended to pay to in the first place.

The transaction [ce75cb…6f6eb4](https://mempool.space/tx/ce75cb0a602fe6089c6c944ebe555d413d55b2ec4df1489cc4275f4cde6f6eb4) actually did signal replaceability. I would guess that you sent all funds from the original wallet and therefore an attempt to rbf-bump the transaction failed because there were neither a change output nor additional funds to increase the feerate. The wallet doesn’t know that you’re trying to send to yourself, so it wouldn’t automatically reduce the recipient amount to increase the fees.

You could try to:

* use child-pays-for-parent from the receiver wallet to reprioritize this transaction
* manually “abandon” the old transaction on the old wallet and create a new transaction with a higher feerate that uses at least one of the same inputs to create a conflict and supersede the original transaction. Since the current mempool conditions are such that most nodes have evicted all transactions with feerates below 3 ṩ/vB, your new transaction would easily propagate even if it had not signaled RBF.

Please check out [Why is my transaction not getting confirmed and what can I do about it?](https://bitcoin.stackexchange.com/q/9046/5406) for more information.


---

### Answer by username_2 on 2023-05-05. Score: 0

> Is there a possibility of losing the transmitted value?

No

> Or, about how long, in your opinion, it has to stay in the mempool,

Each node independently decides how long they keep transactions in their mempool

> until it is confirmed.

Or until too old

> Is it possible that it will never be confirmed?

Yes, but the network will accept a later transaction spending the same inputs at a higher fee rate.

> **Comments:**
> **username_0**: Thanks for answers. I am confusing a little bit. I understand  that sooner or later, somehow, the transaction will be accepted with this low fee, by a miner/node. I don't realize what means too old in mempool. Anyway obviously I can't initialize send another transaction with the necessary fee to be confirmed. As I say Replace-by-fee is not possible. All these aspects result in the loss of the transaction value. That I consider not wright and fair. In this case, the Bitcoin Core wallet should not allow transactions under any circumstances to avoid this kind of extremely embarrassing situations.  

---

