False "conflicted" status #6023

IRC user "CryptoSiD" reports that after restarting 0.10.1rc2, it displayed "conflicted" for two of the transactions he sent until he ran with -rescan (during which the transactions in question were mined). Specific txids, getinfo/getblockchaininfo, and debug.log are stored on my PC as "20150417-CryptoSiD-conflicted-issue" to respect the user's privacy - I can share these privately with other developers.

During the problem, getrawtransaction could not find the transactions. This suggests it was not in the mempool. User reports that he did not change versions or do anything abnormal between restarts or to send the transactions. I am unsure where we add wtx to the mempool at startup - assuming we do? Either way, we shouldn't report "conflicted" for a transaction just because it isn't in the mempool... even if we rejected it for some good reason (eg, different policies than when the tx was sent).

I think the correct solution is to have a mechanism for checking a transaction against the mempool, without necessarily adding it. This checking could use weaker script validation flags too.

@luke-jr: Sounds like the issue I described here: #5511

During startup, when adding pending wallet transactions, which spend outputs of other pending wallet transactions, back to the memory pool, and when they are added out of order, it appears as if they are orphans with missing inputs.

Those transactions are then rejected and flagged as "conflicting" (= not in the memory pool, not in the block chain).

#5511 was merged, so this seems fixed. Closing