<p>Well, you can initiate the transaction with same input referenced,  but the node in the network will not add your transaction in their mempool, since they already have an transaction with same input.</p>
<p>What you can do-</p>
<ol>
<li><p>Wait till the first transaction gets discarded from mempool(it may take long time, tho) and then re-initiate a transaction with significant transaction fee.</p>
</li>
<li><p>Tell the receiver to initiate a new transaction to his own wallet spending the output of the <strong>verified but unconfirmed transaction</strong> (i.e the transaction stuck in mempool) with a slightly high transaction fee. This is called Child Pays for Parent (CPFP) transaction.</p>
</li>
</ol>

CC BY-SA 4.0
2021-06-16T22:28:40.890Z
2021-06-24T20:07:37.097Z
2021-06-24T20:07:37.097Z
Ali Mobasshir
<p>In the <a href="https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages" rel="nofollow noreferrer">protocol rules</a> for validating transactions it says:</p>

<p>Rule 9:</p>

<blockquote>
  <p>For each input, if the referenced output exists in any other tx in the
  pool, reject this transaction.<a href="https://en.bitcoin.it/wiki/Protocol_rules#cite_note-5" rel="nofollow noreferrer">[5]</a></p>
</blockquote>

<p>I assume that when a node receives a transaction it has to validate it applying those rules before adding it to the <strong>memory pool</strong> and resending it. Also miners will only add transactions to blocks if they are validated, that is, they are in the memory pool. Please correct me if I'm wrong.</p>

<p>Let's say I broadcast a valid transaction with such a low fee that no miner is willing to add it to a block, but it is valid, nodes who received it validated it and miners also validated it but it is stuck in the limbo, it is not in any block so the recipient cannot reference any output in this transaction.</p>

<p>Is there any way of re-spending the inputs referenced in this transaction? I think I have to wait until the transaction is removed from the memory pool of the miners but I'm not sure. If this is true, how long does it take?</p>

<transactions><unconfirmed-transactions><transaction-verification>
Double spend a tx output already spent but unconfirmed because of low fee
miguel
# Double spend a tx output already spent but unconfirmed because of low fee

(Asked by: username_0 on 2017-03-07)

In the [protocol rules](https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages) for validating transactions it says:

Rule 9:

> For each input, if the referenced output exists in any other tx in the
> pool, reject this transaction.[[5]](https://en.bitcoin.it/wiki/Protocol_rules#cite_note-5)

I assume that when a node receives a transaction it has to validate it applying those rules before adding it to the **memory pool** and resending it. Also miners will only add transactions to blocks if they are validated, that is, they are in the memory pool. Please correct me if I'm wrong.

Let's say I broadcast a valid transaction with such a low fee that no miner is willing to add it to a block, but it is valid, nodes who received it validated it and miners also validated it but it is stuck in the limbo, it is not in any block so the recipient cannot reference any output in this transaction.

Is there any way of re-spending the inputs referenced in this transaction? I think I have to wait until the transaction is removed from the memory pool of the miners but I'm not sure. If this is true, how long does it take?

**Tags:** transactions, unconfirmed-transactions, transaction-verification


---

## 1 answers

### Answer by username_1 on 2021-06-16. Score: 1 | Accepted answer

Well, you can initiate the transaction with same input referenced, but the node in the network will not add your transaction in their mempool, since they already have an transaction with same input.

What you can do-

1. Wait till the first transaction gets discarded from mempool(it may take long time, tho) and then re-initiate a transaction with significant transaction fee.
2. Tell the receiver to initiate a new transaction to his own wallet spending the output of the **verified but unconfirmed transaction** (i.e the transaction stuck in mempool) with a slightly high transaction fee. This is called Child Pays for Parent (CPFP) transaction.


---

