Somehow my balance got corrupt.
Only the 2 last transactions I made appear.
I tried to cause a rescan by changing to testnet and back to mainnet, but it did not work.
I hear often that the balance get's corrupted.
How about a Rescan block filter option in the settings?
I can probably do that when my last 2 PR get merged. It is easy: We can put a marker file in the data directory, when we restart, it should delete all state if the marker file is here.
@NicolasDorier Did the incorrect balance happen on the master branch or with the released version?
master branch
that said, I messed up and sometimes ran the released version after the master branch by mistake.
Hello! I was looking for an issue to help contribute to Wassabi and this one got my attention.
So, for now I don't know exactly how the pruned node runs "under" Wasabi, but I saw this rpc command on the latest Bitcoin Core version which could be useful to make the rescan possible without a restart.
wasabi does not use RPC.
Hmm :thinking: okay I assumed that it used for this because it is being used here
Anyway, I'll keep trying to understand the codebase before trying to help :)
this is the coordinator, not the wallet.
@johnnyasantoss The WalletWasabi.Backend folder is the CoinJoin cordinator, the rest, for the most part, is the wallet
I've had a similar issue, where certain transactions/coins were missing from the wallet, this fixed itself after a resync. You could try to backup and move/rename the Block/Transaction folders to force a rescan of previous transactions?
Just dropping in to say that #2031 would be a quick fix to this :)
Status report on this. https://github.com/nopara73/NoparaFaq/blob/master/README.md#spent-coin-status-in-wasabi
Status report on this. https://github.com/nopara73/NoparaFaq/blob/master/README.md#spent-coin-status-in-wasabi
Unfortunately the switch to TestNet and back did not work for me either. I'm only running current release version.
I trigger these log entries when trying to spend the (already spent) coin:
INFO CcjClientState (37) Coin added to the waiting list: #:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
INFO CcjClient (805) Coin queued: #:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
WARNING CcjClient (586) Provided input is not unspent: #:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
INFO CcjClientState (57) Coin removed from the waiting list: #:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
INFO CcjClient (1034) Coin dequeued: #:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. Reason: Failed to register the coin with the coordinator. The coin is already spent..
Any chance the spending coin is unconfirmed?
Any chance the spending coin is unconfirmed?
No, the spending tx was confirmed weeks ago.
@jonathancross Can you delete the IndexStore folder (and clear the wallet cache simultaneously)? If it'd fix it, we could ensure our issues are with the index file rather than with the wallet cache.

@nopara73 Unfortunately, no this didn't work either even though I saw that everything in the _IndexStore_ was rebuilt.
Is it enough to switch then quit then switch back, or should the wallet be loaded when switching to TestNet before switching back to Main?
@jonathancross That's correct workflow. The only other idea I have is to delete the whole data folder with the exception of wallet files, but that doesn't give us much diagnostic information.
Is there any chance that it's just a throwaway test wallet of yours so you wouldn't mind sharing the extpub?
Is there any chance that it's just a throwaway test wallet of yours so you wouldn't mind sharing the extpub?
Unfortunately not. It is not actually my wallet and the owner would not be comfortable with releasing the xpub (undermining the benefit from all coinjoins).
...delete the whole data folder with the exception of wallet files...
Right now it's not a big deal for the owner and I'm happy to help debug more if you need more info. If there is nothing further that would help the team debug, then we'll go ahead and do this.
If there is nothing further that would help the team debug, then we'll go ahead and do this.
I mean, even this is an important diagnostic data if it fixes it. I cannot imagine how it'd do that though, but if it does, then we may be able to narrow it down to a one or two things that has the most likelyhood of ruining anything.
@lontivero @molnard any theories?
FWIW: Apparently there were some internal transfers, as in: a new address was generated, then part of a mixed coin was sent to that (in order to meet the minimum amount required to participate in another round with other coins).
That is probably too vague to be helpful, but it seems something got confused with what was "change", what was "sent", and / or what participated in a CJ, etc. Sorry I can't offer more info.
Upon investigating the issue I found a possible way how this can happen. @NicolasDorier it seems like NBitcoin's P2P block notifications are unreliable, so it's possible we missed to build a filter for a few blocks.
I wrote a test that reproduces the issue: TrustedNotifierNotifiesBlockAsync
In this test I create 10 blocks, but we don't get notified about all the 10 blocks.
@lontivero checked the network traffic. It seems like NBitcoin is working correctly, but Bitcoin Core doesn't give us enough block invs.
Issue opened: https://github.com/bitcoin/bitcoin/issues/17451
Will workaround somehow in the meantime.
Should be fixed on master.