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).
To prevent this, transactions are explicitly sorted.
oh erp. Yea, good find.
I don't believe that chrnological order (really nOrderPos order in your patch) always means dependency order, however. Do you have a way to reproduce the behavior you're fixing?
I assumed that transactions are not added out of order to the wallet, because it appears as if they have to pass certain checks to be added to the wallet in the first place, and that nOrderPos reflects correct dependency order. If this is questionable, then this approach might not cover all situations.
A simple test to check, if a client adds unconfirmed transactions back to the memory pool in correct order:
As RPC test: https://gist.github.com/dexX7/06df91d1a7f99190d8d6
I'd say that transactions generated by the wallet itself, which are the ones useful to insert into the mempool, are always in dependency order by nOrderPos, so this makes sense.
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).
To prevent this, transactions are explicitly sorted.
Rebased (src/wallet.cpp -> src/wallet/wallet.cpp).
Tested with the above linked test a few hundred times, although I can't say in which case nOrderPos might actually not reflect dependency order, and the test only shows it works well under those specific test conditions. It can be used to show the current failure though: sample log output and comparison
utACK
utACK
As a wallet user who has this issue and a lot of BTC in this status what can be done to get them back?
Hey @willstg,
fortunally this is only a local issue, and your BTC are not lost.
Please create a backup of the wallet nevertheless.
Shutdown Bitcoin Core before continuing.
Depending on the OS, the default wallet locations are:
$HOME/.bitcoin/wallet.dat$HOME/Library/Application Support/Bitcoin/wallet.dat%APPDATA%/Bitcoin/wallet.datTo clear the conflicted transactions, start bitcoind or bitcoin-qt with the command-line option -zapwallettxes.
Alternatively, zapwallettxes=1 can be added to the bitcoin.conf, but should be removed after the first startup.
zapwallettxes clears the wallet transactions, and then scans the blockchain to find and add only those, which are actually in the chain (the non-conflicted ones).
If you had a bunch of unconfirmed transactions, then it could be that not all, but only some, or maybe even none, are going to be confirmed. This depends on whether other nodes received the transactions (and ultimately the miners).
There is also a chance that other nodes received the unconfirmed transactions, but your local client doesn't know anything about them after zapping, so please wait some time, ideally a few blocks, until you resend the transactions, which didn't go through.