3

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?

5
  • 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
    Commented Feb 17, 2014 at 19:11
  • 1
    Thanks. Can you point me to a certain part of the source code where I can check to make sure?
    – Emre K.
    Commented Feb 17, 2014 at 19:54
  • 2
    @AntonAnsgar Here is where stale transaction removal happens. removeConflicts checks memory pool for conflicting inputs here.
    – John T
    Commented Feb 17, 2014 at 21:33
  • @JacobTorba Can you write an answer so I can mark as valid? Thank you.
    – Emre K.
    Commented Feb 18, 2014 at 7:06
  • @AntonAnsgar you got it.
    – John T
    Commented Feb 18, 2014 at 15:54

2 Answers 2

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, removeConflicts is defined here.

4
  • 1
    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.
    Commented Feb 20, 2014 at 16:08
  • That method removes conflicting transactions from the memory pool, not from the wallet. Commented Feb 20, 2014 at 17:41
  • @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: bitcoin.stackexchange.com/questions/22663/…
    – Emre K.
    Commented Feb 25, 2014 at 21:33
  • 1
    I just figured out from the answer of Pieter to question: bitcoin.stackexchange.com/questions/22663/… that the existing removeConflicts code does not deal with this issue.
    – Emre K.
    Commented Mar 9, 2014 at 13:57
-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.

4
  • The question is not whether it can be spent. The question is whether the situation described in the question is possible
    – Emre K.
    Commented Feb 17, 2014 at 19:46
  • No this is not possible.
    – T9b
    Commented Feb 17, 2014 at 21:36
  • Really? How? Do you know which part of the source code is going to delete the first transaction?
    – Emre K.
    Commented Feb 17, 2014 at 22:21
  • 1
    I just learned that it is indeed possible. See: bitcoin.stackexchange.com/questions/22663/…
    – Emre K.
    Commented Mar 9, 2014 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.