In 0.12, a wallet tx thats not in the mempool does not free up its inputs.  So if a tx spends the same inputs as a conflict tx included in a new block, its inputs are explicitly marked dirty so they will be recalculated as spendable again due to having no non-conflicted spends.  However if the in-block conflict is reorged out, the wallet txs inputs should now be market spent again according to the 0.12 regime, but they are not marked dirty as the tx itself is not notified it is no longer conflicted.

This has the odd effect that the cached value is incorrect and so randomly they will be spendable or not depending on whether they have been recalculated.

This is easy enough to fix by marking all inputs of all txs in SyncTransaction dirty regardless of whether AddToWalletIfInvolvingMe returns true or false.  But I'm not sure the performance impact this will have, so I'm not proposing that change now.

It's a minor issue, but I just thought I'd document that that the cached credit available in wallet txs may not always be correct.

For reference, in 0.11, whenever a tx left the mempool it's inputs were respendable.  So if a tx was removed due to a conflict in a block, any remaining inputs would be spendable again.  If the in-block conflict was later reorged out, the wallet txs inputs would remain spendable unless and until the wallet tx reentered the mempool.

{
    // Don't attempt to resubmit if th is configured to not broadcast
    if (!fBroadcastTransactions) return false;
    // During reindex, importing and IBD, old wal transactions become
    // unconfirmed. Don't resend them as that would spam other nodes.
    // We only allow forcing mempool submission when not relaying to avoid this spam.
    if (!chain().isReadyToBroadcast()) return false;
    // Do this infrequently and randomly to avoid giving away
    // that these are our transactions.
    if (NodeClocknow() < m_next_resend) return false;
    return true;
}
NodeClocktime_point CWalGetDefaultNextResend() { return FastRandomContext{}.rand_uniform_delay(NodeClocknow() + 12h, 24h); }
// Resubmit transactions from th to the mempool, optionally asking the
// mempool to relay them. On startup, we will do this for all unconfirmed
// transactions but will not ask the mempool to relay them. We do this on startup
// to ensure that our own mempool is aware of our transactions. There
// is a privacy side effect here as not broadcasting on startup also means that we won't
// inform the world of our wal's state, particularly if th (or node) is not
// yet synced.
//
// Otheise this function is called periodically in order to relay our unconfirmed txs.
// We do this on a random timer to slightly obfuscate which transactions
// come from our wal.
//
// TODO Ideally, we'd only resend transactions that we think should have been
// mined in the most recent block. Any transaction that wasn't in the top
// blockweight of transactions in the mempool shouldn't have been mined,
// and so is probably just sitting in the mempool waiting to be confirmed.
// Rebroadcasting does nothing to speed up confirmation and only damages