rpc/getbalance: totalimmaturestakegeneration return is higher than actual.

[JoeGruffins]

This started very recently on mainnet. When getting balance the total immature stake generation is shown as almost as much as my entire actual balance. This is added to the cumulative balance so that to is also off now. Have tried rescanning with a very high gap limit, reseeding, and running on master (was using 1.6.3 when it started) but the balance is the same.

The start up log has one error that is new I believe, and may or not be related. This is also shown directly after reseeding:

2021-11-02 12:41:35.885 [INF] WLLT: Rescanning block range [603482, 603485]...
2021-11-02 12:41:35.892 [INF] WLLT: Rescan complete
2021-11-02 12:41:35.894 [WRN] SYNC: Could not publish one or more unmined transactions: wallet.PublishUnminedTransactions:: dcrd.PublishTransactions: rejected transaction **redacted**: orphan transaction **redacted** references outputs of unknown or fully-spent transaction **redacted**
2021-11-02 12:41:35.895 [INF] SYNC: Blockchain sync completed, wallet ready for general usage.
2021-11-02 12:41:36.066 [ERR] WLLT: Failed to sign revocation for ticket hash **redacted**: txscript.SignTxOutput: transaction script fails to execute:: wallet locked: default

I had not noticed the SYNC warning before. The other error about revocations was there already.

This is a seed I have been using for maybe 2+ years, so has a bit of use.

[jrick]

Can you bisect the wallet between the last database upgrade (b728836) and the current master branch and see if/where this began happening?

[JoeGruffins]

This started happening on release-v1.6.3 out of the blue, so I don't believe the db was upgraded by that commit.

[JoeGruffins]

I'm thinking the log is unrelated. I probably just didn't notice it.

I wonder if it has something to do with the tickets that are reported missed being expired by now. It looks like the balance does come from those revocations, but I wasn't seeing them added before.

[JoeGruffins]

Or, maybe I started my wallet with it unlocked and then it got the tx hash it keeps trying to send. I didn't see it before because I never started my wallet unlocked, so it had no chance to sign, store, and try to send. That's why it still does this after reseeding, because it is always unlocked the first go.

[JoeGruffins]

Ok. I am pretty sure this is a symptom of #2052

After reseeding and shutting down after the keys are derived but before sync is completed and txs sent, the balance is correct.

I expect that anyone who voted on the treasury spend will see a bugged balance if they open their wallet while it's unlocked. If someone could confirm would be great. I think @davecgh may have a wallet to look at that voted then?

[JoeGruffins]

Although #2052 seems to be resolved, the wallet will continue to try and send the transactions it stored and my balance is still off for the existing database. Maybe it should give up on sending transactions after certain errors that are probably not recoverable? Like spending a non-existent UTXO like the ticket that we thought was missed in this case.

[JoeGruffins]

@davecgh suggested that I try abandontransaction. I did that for all the txs that showed up in error at startup and then after a rescan, the balance is fixed and the error messages are gone.

However, I still think this should be automatic in some cases. Also, I had to start up wallet multiple times because it only tells me one tx hash per error.

Also also, the txs do not show up in listtransactions or any other rpc calls that I can tell.