Bisq does not retain bitcoin addresses & transactions following wallet recovery (OP: 'erases all state data when launched alongside Bitcoin core')

[mattmill30]

Description

Bitcoin core GUI with default settings was running when Bisq was launched. A notification "Bisq detected a locally running Bitcoin Core node (at localhost)", with 'Close' being the only option.

However, the Bisq interface and state has completely re-initialised, and even when relaunched once Bitcoin Core has been shutdown, Bisq does not reverse to it's previous state with a populated Available balance or long list of Transactions, Receive Funds addresses.

Version

v1.3.4

Steps to reproduce

1. Launch Bitcoin core
2. Launch Bisq

Expected behaviour

Depending on the desired Bisq behaviour, either an error message prior to bootstrap stage 1 stating that "Bisq deteced a locally running Bitcoin Core note (at localhost)", with atleast 2 options:

1. Shutdown Bisq without saving any changes
2. Re-initialise Bisq, and erase all Bitcoin addresses, transactions and balance.

Actual behaviour

Screenshots

Bisq detected a locally running Bitcoin Core node:

Bitcoin addresses in Receive Funds have been erased:

Funds > Transactions has also been erased:

Also, note the occasional Bitcoin sync error in the status bar.

Device or machine

Win 10 64-bit

Additional info

bisq.log

[mattmill30]

I attempted to reverse the re-initialisation by replacing the files in Bisq/Btc_mainnet/{db,keys,wallet} with backup files from prior to the erasure, but the balance, transaction and receive funds addresses remain re-initialised.

The files which were reverted to backup versions were:
db:

• AddressEntryList
• BallotList
• NavigationPath
• PeerList
• PreferencesPayload
• SequenceNumberMap
• UnconfirmedBsqChangeOutputList
• UserPayload

keys:

• enc.key
• sig.key

wallet:

• bisq_BSQ.wallet
• bisq_BTC.wallet

The files which couldn't be reverted because backup versions weren't available, so the re-initialised version was left in place:
db:

• AccountAgeWitnessStore
• BlindVoteStore
• DaoStateStore
• ProposalStore
• SignedWitnessStore
• TempProposalStore
• temp5984691532433223798.tmp
• temp9985995058067816881.tmp
• TradeStatistics2Store

wallet:

• bisq.spvchain
• wallet516136899857780891.tmp
• wallet14528095496907500296.tmp

[mattmill30]

I anticipate this is possibly an unintended consequence of the fix to #3935 .
The "misconfigured local Bitcoin node" dialog #3982 , with the option to 'continue without using local node' would be an appropriate third option to the dialog I suggested

[dcod3d]

Did you whitelist bloomfilter in core?

[mattmill30]

I didn't customise the Bitcoin Core client configuration at all because I wasn't intending to integrate Bisq and Bitcoin Core. I didn't realise this was an option. So I incidentally launched Bisq while Bitcoin Core client was running, because I was unaware there would be a conflict.

[dcod3d]

Did you recently update core? The default configuration stopped working at 0.19 and requires whitelisting bloomfilters. Looking at the tail end of your logs, its only trying to connect to your local node and keeps dying.

Try adding this to your bitcoin.conf and restarting:
whitelist=bloomfilter@192.168.0.17

[mattmill30]

I have updated core to 0.20.
Am I correct that you're attempting to integrate Bisq and Bitcoin Core, by adding bloomfilter to the Core whitelist?
What affect will using Bitcoin Core have on Bisq?
Up until this accidental execution of Bisq while Bitcoin Core was running, I have been using the standard Bisq setup, which I understand uses bitcoinj.
Does this not mean that all previous Bisq transactions require the bitcoinj wallet, which wouldn't be available if Bisq switches to using Bitcoin Core?

[dcod3d]

Bisq uses bitcoinj to connect to nodes. So previously, your Bisq client was connecting to third party nodes. Now that it detected a local node, it's trying to connect to it but failing because of bloomfilter. I'm also assuming you're running Bitcoin Core as a full node.

[mattmill30]

So the 0.19+ issue you were referring to is resolved with the bloomfilters fix?
Will BitcoinJ continue to resolve against remote nodes if my local Bitcoin Core isn't running in the future?

[dcod3d]

Yes. You can change what nodes you use in Bisq’s network settings. Although in the spirit of decentralization, you should use your own node.

[mattmill30]

If it's the case that Bitcoin Core can be switched into use with Bisq, why has Bisq therefore completely re-initialised and erased all my previous balance, transactions and receive funds addresses, when Bisq happened to launched while Bitcoin Core was already running?

[mattmill30]

Because this issue is alongside #4307 , I attempted to recover the missing transactions by renaming the Bisq datadir and launched a fresh Bisq instance.
Then I attempted to recover the wallet using the seed phrase, which was successful, and all transactions were recovered.
However, after shutting down and relaunching Bisq, all transactions were once again erased. Except for 1 receive address, which was 0 BTC, but marked as 1 confirmed transaction.
Bitcoin Core was not running this time, so it would appear to be co-incidental that Bisq erased the datadir at the same time as detecting Bitcoin core.
But it still doesn't explain why Bisq is erasing itself when relaunched. I will attempt a second wallet recovery with a fresh Bisq datadir to confirm the fault recurs following the above procedure

[mattmill30]

After repeating the steps detailed in the above comment, the transactions and balance is recovered, but Bisq does not correctly retain the transactions and balance between shutdown and relaunch.
(#4318 (comment))

Prior to shutting down Bisq following a successful wallet recovery, 6 addresses were populated with Bitcoin. After shutting down and relaunching Bisq, it now displays:

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.