Wallet shows nnn balance for address xxx but the block explorer shows zero

[ghost]

Version: 1.5.0

From keybase:

tobmat 8:07PM
This issue is happening because there are fund spended before that are show as available by bsq. When bsq broadcast the TX yo blockchain fail because there are not funds, despiste bsq shows.
If You try to fund an offer by sending btc from external wallet it goes good. Try and You Will see. To withdraw check all address with funds on blockchain and You Will see some without funds on blockchain. So select only those that have btc on it and You Will be able to withdraw

chimp1984 8:19 PM
@tobmat if u have txs which are ntot confirmed and not found in external explorer then do a spv resync so those get cleaned up

jmacxx 9:13 PM
I helped a different user with the same problem this morning. Bisq wallet reported a certain address having funds, but the blockchain showed that address had already been used in a trade. Multiple SPV resyncs and always the same address came up as having a balance when in reality it did not. The result was that trade attempts failed, and wallet withdraws could not be done. We resorted to moving funds out using electrum and starting fresh with a clean Bisq directory.
I thought it was a one-off occurrence until reading @tobmat's description above which matches completely.

@oscarguindzberg ☝️ I DM'd you the log from this issue.

[chimp1984]

@jmacxx Did the user tried a restore from seed words in a new Bisq app as well?

I had investigated a similar issue of @MwithM. There have been 3 times a deposit tx not being stored in the wallet but at the time it was created all looked ok. The trades completed as well. But later as the spending (deposit) tx seems to have been lost (not sure yet as its 3 weeks ago and the user did some spv resyns in between) the outputs from the trade fee tx was considered unspent in Bisq, even it was spent. A restore from seed cleaned all up and balance was also confirmed with importing the seeds in electrum (one need to make 2 wallets there, one for legacy and one for segwit - and BSQ has to be considered as well).

I highly recommend to NOT use Electrum for sending out funds (for cross checking the balance its ok) as specially with BSQ things can go very wrong (BSQ burned) and if Bisq app is still in use Bisq data can get screwed up. Also getting out funds vai Bisq always works (at least I have not seen any case so far where it did not work - and if there are cases we need to find out the reason to fix it).

[ghost]

I thought an SPV resync of the wallet was mostly the same operation & did not think to do a separate restore from seed. I'll take heed of that advice in the future.

I did suggest to the user that we pass the issue to Oscar to take a look at, but the user wanted an immediate resolution and opted for electrum. He did save his old data directory, so theoretically the problem could still be investigated with his cooperation.

[chimp1984]

I thought an SPV resync of the wallet was mostly the same operation

SPV resync rebuilds the spv file but not the wallet directly. With restore from seed a new wallet gets created. I am also not very familiar with the internal of the wallet data and spv file... In the past a SPV resync was sufficient. I don't remember any case where a restore from seed was needed.

[ghost]

Seems that this issue (UTXOs already spent but wallet does not know they are spent) could quite probably be fixed already by bitcoinj/bitcoinj#2070 and #4903.

[chimp1984]

Seems that this issue (UTXOs already spent but wallet does not know they are spent) could quite probably be fixed already by bitcoinj/bitcoinj#2070 and #4903.

Unfortunately it seems it is not fixed. We tested with a corrupted wallet and spv resync did not recover the missing txs, only a restore from seed. From my understanding a relevant wallet tx should be recovered from the network by a SPV resync.
@oscarguindzberg Is that assumption correct?

[oscarguindzberg]

#4962 will be merged into 1.5.2
It will probably prevent this bug from happening again.
An spv resync will be required once 1.5.2 is released to fix wallets that already show this problem.

[ghost]

Fixed by bitcoinj 0.15.8.bisq.13 / #4962.