<p>Assuming most of the nodes on the network run with the default configuration of <code>maxmempoolexpiry</code>, most of the network mempools will drop your transaction after 336 hours (2 weeks).</p>
<p>You should have crafted your transaction such that it signals BIP125 replaceability (by having at least one of the input nSequence <code>&lt;= 0xfffffffd</code>).</p>
<p>At this point, you could use CPFP (spend the output you just created with a high fee-paying transaction paying for the whole package) or use a pool &quot;transaction accelerator&quot; to send a new version of your transaction paying higher fees.</p>
<p>See also <a href="https://bitcoin.stackexchange.com/questions/9046/why-is-my-transaction-not-getting-confirmed-and-what-can-i-do-about-it">Why is my transaction not getting confirmed and what can I do about it?</a> .</p>

CC BY-SA 4.0
2020-12-31T12:14:49.297Z
Really annoying. For cpfp,  I m getting `input does not exists`, it seems transactions accelerators don t accept bare multisig. Is there a way to get my money without facing such huge price volatility risk?
user2284570
CC BY-SA 4.0
2020-12-31T12:22:27.317Z
I personally think we should always signal for RBF: "you can't predict the block space market ":) For your CPFP issue it means your node isn't aware of your transaction yet (maybe there is hope here?), or you miscrafted your child transaction.
Antoine Poinsot
CC BY-SA 4.0
2020-12-31T12:24:47.070Z
It appears in the transaction list, so I d rather say it considers the input as already spent because being in the mempool.
user2284570
CC BY-SA 4.0
2020-12-31T12:25:26.853Z
No, the error is not the same on conflicting transactions.
Antoine Poinsot
CC BY-SA 4.0
2020-12-31T11:57:34.427Z
2020-12-31T11:57:34.427Z
Antoine Poinsot
<p>I sent a bare $1000 multisig transaction using <code>sendrawtransaction</code> with a too low fee.</p>
<p>When I create a new transaction with a higher fee, I m getting <code>txn-mempool-conflict</code> error, and when I use the <code>bumpfee</code> command, I m getting <code>Transaction is not BIP 125 replaceable</code>.</p>
<p>So given I sent it yesterday, in how much time I would be to access the money again?</p>

<transactions><transaction-fees><unconfirmed-transactions><mempool><bip-125-replaceable>
What is the network mempools unconfirmed transaction expiration time?
user2284570
# What is the network mempools unconfirmed transaction expiration time?

(Asked by: username_0 on 2020-12-31)

I sent a bare $1000 multisig transaction using `sendrawtransaction` with a too low fee.

When I create a new transaction with a higher fee, I m getting `txn-mempool-conflict` error, and when I use the `bumpfee` command, I m getting `Transaction is not BIP 125 replaceable`.

So given I sent it yesterday, in how much time I would be to access the money again?

**Tags:** transactions, transaction-fees, unconfirmed-transactions, mempool, bip-125-replaceable


---

## 1 answers

### Answer by username_1 on 2020-12-31. Score: 2

Assuming most of the nodes on the network run with the default configuration of `maxmempoolexpiry`, most of the network mempools will drop your transaction after 336 hours (2 weeks).

You should have crafted your transaction such that it signals BIP125 replaceability (by having at least one of the input nSequence `<= 0xfffffffd`).

At this point, you could use CPFP (spend the output you just created with a high fee-paying transaction paying for the whole package) or use a pool "transaction accelerator" to send a new version of your transaction paying higher fees.

See also [Why is my transaction not getting confirmed and what can I do about it?](https://bitcoin.stackexchange.com/questions/9046/why-is-my-transaction-not-getting-confirmed-and-what-can-i-do-about-it) .

> **Comments:**
> **username_0**: Really annoying. For cpfp,  I m getting `input does not exists`, it seems transactions accelerators don t accept bare multisig. Is there a way to get my money without facing such huge price volatility risk?  
> **username_1**: I personally think we should always signal for RBF: "you can't predict the block space market ":) For your CPFP issue it means your node isn't aware of your transaction yet (maybe there is hope here?), or you miscrafted your child transaction.  
> **username_0**: It appears in the transaction list, so I d rather say it considers the input as already spent because being in the mempool.  
> **username_1**: No, the error is not the same on conflicting transactions.  

---

