Available Balance != BTC AVAILABLE

I have a confusing problem. I have two instances using the same wallet/seed but showing different balances. Same Wallet, Different Balances - #9 by MnM

To debug, I used CTRL-J to show Wallet Data. Under this window, the Balances: section shows an amount for BTC AVAILABLE that is not equal to the Available Balance amount in the upper-right of the UI. Instead, this BTC AVAILABLE is equal to the Available Balance amount in the upper-right of the other Bisq instance.

So that’s good I guess (especially because it is the larger balance) and I guess it means that this is the true amount.

But can anyone explain how the UI Available Balance would show a value that is not equal to the BTC AVAILABLE in the Wallet Data?

I am running v1.9.8 and I synced the SPV four times.

You should never user two instances running with the same wallet! It is possible you have open offers in one, that the other doesn’t know about, so the former will show a smaller available balance, the latter the full available balance including the reserved amount for the offer.
So do NOT use same wallet with two apps, only use one of them.
You could use them alternatively, always syncing between the two after each use, but that’s very error prone and inconvenient.

BTW, could we say this is a “two instances, one wallet” scenario? :rofl:

Right. But for one thing, I am not doing that. I am running one. And for another, the creation of the second wallet already happened. So this admonition does not help with this post.

The goal here is to figure out why the UI and the CTRL-J do not match each other inside the same instance.

What do you mean by syncing between wallets? Maybe that would fix the original problem, but it still would not explain the problem here, which is that the UI and CTRL-J do not match. How is this not very worrying to everyone? If the UI can not be truste to display the actual balance that the same instance is aware of?

I am now confused.
Quoting your OP, “I have two instances using the same wallet/seed but showing different balances”, is that not the situation?
Bisq wallet is not your average wallet. It is made to manage:

  • “normal” balance
  • BSQ balance
  • BTC “available for spending but reserved” for standing open offers

My hypothesis is that you have an open offer, that is reserving a certain amount of your BTC as the potential deposit amount, and which is this reducing the available BTC in the UI. This same balance is still spendable by all means, so it should be shown in the advanced wallet info inside the same application.

As for the “syncing between two wallets”, it’s something I’d rather not even explain, to not give any ideas to people, as it is error prone as I stated, and not supported in any case. For all purposes, “one wallet, one instance, one machine” is the way Bisq should be used :wink:

It is. But I am not running both. I have them, I can access either one.

I am not worried as much about the balance as I am about not being able to trust the UI to tell me how much BTC I have. That’s why I made this separate, since my personal issue is different from the general issue of the balance and the CTRL-J balance to be different.

It’s a good hypothesis, except that I am 98% sure I don’t have an open offer. But how can I test this hypothesis to be sure?

You don’t need to run both instances of same account at the same time for issues to arise; as long as there are more than one instance with the same wallet that are used, even alternatively, the wallet is bound to get mismatched in at least one of those, possibly in all, that is why, rather than trying to find the exact source of the issue, now that we know that you run the same wallet account on two applications, I would suggest you choose which instance you will be using from now on and drop the other.
You might have had an open offer, or a failed trade, or whatever activity implied txs in your wallet that were recorded by one instance and not the other, and this would impact in the wallet state.

Once you have done this, it should suffice to start a SPV resync (or sometimes more than one, if you are not using your own bitcoin node on local network) to bring the wallet to its correct state

But as I pointed out, resyncing the SPV multiple times did not make the older instance match the newer one. That’s why I opened this post. Because the UI and the CTRL-J balances do not match, and that seems like a bug. The question in this post is “can anyone explain how the UI Available Balance would show a value that is not equal to the BTC AVAILABLE in the Wallet Data?”

This post is not about getting me running again, it’s about figuring out why the UI and the CTRL-J balances are different.

1 Like

How much if the balance off by? Are you adding the available balance to the reserved balance?

Also not sure if dust amounts are shown in the UI to prevent dust attacks.

There are a few places to check your balance:

Top right of the Bisq UI (you need to add Available balance with the Reserved balance, as both funds make up the balance in your BTC wallet)

Pressing CTRL-J to access the emergency wallet

Account > Wallet info - you can see BTC and BSQ balances here

Funds > Send Funds + Reserved Funds should equal total amount of BTC

Occasionally some users will also have BTC in their BTC wallet - see DAO > BSQ wallet

Available + Reserved = Balance shown in emergency wallet

Balance shown in emergency wallet = Wallet info balance

Send funds = available balance

Reserved funds = reserved balance

Hi, thank you for writing and this would have been useful on the other ticket (Same Wallet, Different Balances - #9 by MnM)

But this post here is not here to sole my problem, but to point out that there is a difference between the Available Balance in one part of the UI, and in another part.

For this post, it does not matter about my issue, only why is Bisq capable of reading the balance two different ways? What does that say about how Bisq gets information?

Anyway I can not help debug now because I could not wait for this to be fixed. I have initated another offer so things are even weirder if I try to fix the original problem.