Cleanup unconfirmed coinbase outputs from wallet

[ignopeverell]

After some time mining with other nodes, we end up with some unconfirmed coinbase outputs in wallet.dat that linger there forever. They're very likely from orphaned blocks coinbase outputs. I think we could clean those up after a safe number of blocks.

Generally, we may also want to clean up unconfirmed outputs that have been stayed so for a while. Maybe after a few hundred blocks for coinbase outputs (only scenario here is orphaned blocks) and a few thousands for regular outputs (bad relay, blocks full, too low fee, etc).

[antiochp]

Ah that's where they are coming from - you see them for coinbase outputs if you restart the mining node (the old one sticks around in Unconfirmed).
It hadn't clicked that we would see orphan blocks with only a couple of miners running.

For regular txs that end up never being confirmed (for whatever reason) - am I right in thinking these keys are at risk of "replay" if they ever get reused? The tx may not have been confirmed but the recipient may have seen the input.
So we'd want to clean them up by flagging them in some particular state to ensure they never get used in the future.

[ignopeverell]

That sounds correct. Maybe we could just remove them and have the wallet keep some index of the latest keys (so always strictly increment)?

[antiochp]

Yeah - I think keeping an incrementing counter/index in wallet.dat makes a lot of sense.

[sesam]

Current key_derivation_cache might need to go through big amounts of keys. If this happens also outside of wallet recovery, how about storing both key_id and iteration value i in wallet.dat?

And then the highest i in wallet.dat is the counter wanted above, right?

[yeastplume]

@ignopeverell I think you've addressed this in recent wallet work?

[ignopeverell]

Sorry missed the question but I believe I did, where part of the output update process removes older unconfirmed outputs (I think a day old).

[hashmap]

Should we close it?