<p>If you wait for a confirmed transaction you will be fine. The common mistake people/large exchanges make is when they constructed "withdraw" transactions from unconfirmed "deposit" transactions. Those invalidate quickly due to double spend rules. The Satoshi client does this as a last resort when picking unspent outputs. </p>

<p>The code that deals with it is <a href="https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1910" rel="nofollow">here</a>, <code>removeConflicts</code> is defined <a href="https://github.com/bitcoin/bitcoin/blob/b78d1cdf82fb12cc0c8eb9049074b359b9589b7c/src/txmempool.cpp#L113" rel="nofollow">here</a>.</p>

CC BY-SA 3.0
2014-02-20T16:08:36.527Z
I have transactions that are stuck on my wallet. What I mean is I have two TXes which have same inputs same outputs. One of them is confirmed. The other one is waiting unconfirmed. I have multiple TXes that are just stuck like this. Any idea why they might have been created? These transactions are mostly received transactions. There is also one sending transaction where I have the same inputs and outputs but different TX ids for 3 transactions. Again one of them is confirmed. The other two are just stuck. I really need help with this. Thanks a lot.
Emre K.
CC BY-SA 3.0
2014-02-20T17:41:51.423Z
That method removes conflicting transactions from the memory pool, not from the wallet.
Pieter Wuille
CC BY-SA 3.0
2014-02-25T21:33:34.033Z
@PieterWullie Thanks. I don't know what memory pool actually does, I'll take a look. But does that mean that they are in the wallet forever? How can I get rid of them? And do you think this is what is going on with the situation I described in this question: http://bitcoin.stackexchange.com/questions/22663/stuck-duplicate-transaction-in-bitcoinqt
Emre K.
CC BY-SA 3.0
2014-03-09T13:57:30.417Z
I just figured out from the answer of Pieter to question: http://bitcoin.stackexchange.com/questions/22663/stuck-duplicate-transaction-in-bitcoinqt that the existing removeConflicts code does not deal with this issue.
Emre K.
CC BY-SA 3.0
2014-02-18T02:26:51.313Z
2014-02-18T15:54:36.470Z
2014-02-18T15:54:36.470Z
John T
<p>An unconfirmed transaction cannot be spent. End of story really.</p>

<p>But for the sake of completeness, if you try to spend it your transaction will also remain unconfirmed with the person you paid. Neither of these transactions will ever enter the blockchain.</p>

CC BY-SA 3.0
2014-02-17T19:46:24.040Z
The question is not whether it can be spent. The question is whether the situation described in the question is possible
Emre K.
CC BY-SA 3.0
2014-02-17T21:36:58.277Z
No this is not possible.
T9b
CC BY-SA 3.0
2014-02-17T22:21:50.990Z
Really? How? Do you know which part of the source code is going to delete the first transaction?
Emre K.
CC BY-SA 3.0
2014-03-09T13:58:09.997Z
I just learned that it is indeed possible. See: http://bitcoin.stackexchange.com/questions/22663/stuck-duplicate-transaction-in-bitcoinqt
Emre K.
CC BY-SA 3.0
2014-02-17T18:51:05.287Z
2014-02-17T18:51:05.287Z
T9b
<p>Assume I'm using the original client to receive payments. Is the following scenario possible?</p>

<p>My wallet gets notified of unconfirmed transaction with id 12 in which one of the outputs is an address that belongs to me.</p>

<p>Someone changes the id of the transaction to 13 and relays it to the miner who finds the next block.</p>

<p>My wallet gets notified of block that contains transaction with id 13 in which one of the outputs is an address that belongs to me.</p>

<p>Transaction with id 13 gets 6 confirmations but transaction with 12 gets stuck in my wallet as an unconfirmed transaction.</p>

<p>If I'm showing my customers their unconfirmed transactions, then the customer will see a confirmed transaction with id 13 and an unconfirmed transaction with id 12. Is that correct? Or will QT automatically delete the first transaction?</p>

<p>What can I do to prevent this?</p>

CC BY-SA 3.0
2014-02-17T19:11:42.167Z
I think your Bitcoin-Qt would discard its knowledge of *t12* as soon as *t13* gets confirmed as they are doublespends of each other.
Murch
CC BY-SA 3.0
2014-02-17T19:54:13.453Z
Thanks. Can you point me to a certain part of the source code where I can check to make sure?
Emre K.
CC BY-SA 3.0
2014-02-17T21:33:43.760Z
@AntonAnsgar [Here](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1910) is where stale transaction removal happens. `removeConflicts` checks memory pool for conflicting inputs [here](https://github.com/bitcoin/bitcoin/blob/b78d1cdf82fb12cc0c8eb9049074b359b9589b7c/src/txmempool.cpp#L113).
John T
CC BY-SA 3.0
2014-02-18T07:06:47.013Z
@JacobTorba Can you write an answer so I can mark as valid? Thank you.
Emre K.
CC BY-SA 3.0
2014-02-18T15:54:47.907Z
@AntonAnsgar you got it.
John T
<transactions><bitcoin-core><transaction-malleability>
Is transaction malleability an issue when receiving payments?
Emre K.
# Is transaction malleability an issue when receiving payments?

(Asked by: username_0 on 2014-02-17)

Assume I'm using the original client to receive payments. Is the following scenario possible?

My wallet gets notified of unconfirmed transaction with id 12 in which one of the outputs is an address that belongs to me.

Someone changes the id of the transaction to 13 and relays it to the miner who finds the next block.

My wallet gets notified of block that contains transaction with id 13 in which one of the outputs is an address that belongs to me.

Transaction with id 13 gets 6 confirmations but transaction with 12 gets stuck in my wallet as an unconfirmed transaction.

If I'm showing my customers their unconfirmed transactions, then the customer will see a confirmed transaction with id 13 and an unconfirmed transaction with id 12. Is that correct? Or will QT automatically delete the first transaction?

What can I do to prevent this?

**Tags:** transactions, bitcoin-core, transaction-malleability

> **Comments:**
> **username_1**: I think your Bitcoin-Qt would discard its knowledge of *t12* as soon as *t13* gets confirmed as they are doublespends of each other.  
> **username_0**: Thanks. Can you point me to a certain part of the source code where I can check to make sure?  
> **username_2**: @AntonAnsgar [Here](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1910) is where stale transaction removal happens. `removeConflicts` checks memory pool for conflicting inputs [here](https://github.com/bitcoin/bitcoin/blob/b78d1cdf82fb12cc0c8eb9049074b359b9589b7c/src/txmempool.cpp#L113).  
> **username_0**: @JacobTorba Can you write an answer so I can mark as valid? Thank you.  
> **username_2**: @AntonAnsgar you got it.  

---

## 2 answers

### Answer by username_2 on 2014-02-18. Score: 2

If you wait for a confirmed transaction you will be fine. The common mistake people/large exchanges make is when they constructed "withdraw" transactions from unconfirmed "deposit" transactions. Those invalidate quickly due to double spend rules. The Satoshi client does this as a last resort when picking unspent outputs.

The code that deals with it is [here](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1910), `removeConflicts` is defined [here](https://github.com/bitcoin/bitcoin/blob/b78d1cdf82fb12cc0c8eb9049074b359b9589b7c/src/txmempool.cpp#L113).

> **Comments:**
> **username_0**: I have transactions that are stuck on my wallet. What I mean is I have two TXes which have same inputs same outputs. One of them is confirmed. The other one is waiting unconfirmed. I have multiple TXes that are just stuck like this. Any idea why they might have been created? These transactions are mostly received transactions. There is also one sending transaction where I have the same inputs and outputs but different TX ids for 3 transactions. Again one of them is confirmed. The other two are just stuck. I really need help with this. Thanks a lot.  
> **username_3**: That method removes conflicting transactions from the memory pool, not from the wallet.  
> **username_0**: @PieterWullie Thanks. I don't know what memory pool actually does, I'll take a look. But does that mean that they are in the wallet forever? How can I get rid of them? And do you think this is what is going on with the situation I described in this question: http://bitcoin.stackexchange.com/questions/22663/stuck-duplicate-transaction-in-bitcoinqt  
> **username_0**: I just figured out from the answer of username_3 to question: http://bitcoin.stackexchange.com/questions/22663/stuck-duplicate-transaction-in-bitcoinqt that the existing removeConflicts code does not deal with this issue.  

---

### Answer by username_4 on 2014-02-17. Score: -1

An unconfirmed transaction cannot be spent. End of story really.

But for the sake of completeness, if you try to spend it your transaction will also remain unconfirmed with the person you paid. Neither of these transactions will ever enter the blockchain.

> **Comments:**
> **username_0**: The question is not whether it can be spent. The question is whether the situation described in the question is possible  
> **username_4**: No this is not possible.  
> **username_0**: Really? How? Do you know which part of the source code is going to delete the first transaction?  
> **username_0**: I just learned that it is indeed possible. See: http://bitcoin.stackexchange.com/questions/22663/stuck-duplicate-transaction-in-bitcoinqt  

---

