# Temporary solution for DAO resync loop **URL:** \ **Category:** Uncategorized\ **Created:** [June 3, 2024, 11:24am UTC](https://bisq.community/t/temporary-solution-for-dao-resync-loop/12016 "2024-06-03T11:24:12Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![suddenwhipvapor](https://bisq.community/user_avatar/bisq.community/suddenwhipvapor/32/3291_2.png) [@suddenwhipvapor](https://bisq.community/u/suddenwhipvapor)\ **Post date:** [June 3, 2024, 11:24am UTC](https://bisq.community/t/temporary-solution-for-dao-resync-loop/12016/1 "2024-06-03T11:24:12Z")
To all users suffering with the constant dao resync issue at Bisq start, this is how I partially resolved mine, so you maybe want to try it too. After you start bisq, and it returns the error popup, leave it running and check the running bisq.log file (under linux, `tail -f /home/youruser/.local/share/Bisq/bisq.log` and in Windows… well have fun refreshing notepad 😅 ), it should show at some point something like > > We request blocks from peer [devinsn2teu33efff62bnvwbxmfgbfjlgqsu3ad4b4fudx3a725eqnyd.onion:8000](http://devinsn2teu33efff62bnvwbxmfgbfjlgqsu3ad4b4fudx3a725eqnyd.onion:8000) from block height 577747. depending on the seednode you are connected to, and after a while it should start the second batch of blocks, and so on, until current blockheight. When it completed the last batch of blocks, close bisq and try restarting, it may be solved. ---
**Author:** ![suddenwhipvapor](https://bisq.community/user_avatar/bisq.community/suddenwhipvapor/32/3291_2.png) [@suddenwhipvapor](https://bisq.community/u/suddenwhipvapor)\ **Post date:** [June 5, 2024, 4:57pm UTC](https://bisq.community/t/temporary-solution-for-dao-resync-loop/12016/2 "2024-06-05T16:57:06Z")
== ATTENTION == Since I cannot edit the above post anymore, I need to make a new one to amend that. While the method explained above “works”, in my experience it will still lead to an unstable state where Bisq will still ask you to resync the DAO even if you are in consensus with seed nodes. My current “working” solution, is to build Bisq from source (sorry, Windows users…) using this page as a guide: > and making sure to select branch 1.9.16 in the example of the first bullet, so using: `git clone --branch release/v1.9.16 https://github.com/bisq-network/bisq` It will not be rock solid, but at least for a decent amount of time after a DAO resync, you will be synced and able to do normal operations. I do use my own bitcoin node though, so also check out > [@PSA: consider running your own Bitcoin node](https://bisq.community/t/psa-consider-running-your-own-bitcoin-node/12005): > > You must have noticed at least to some degree how Bisq1 connectivity has degraded lately, and you probably know this is about Tor being under DDoS attack since a few weeks ago: [Performance – Tor Metrics](https://metrics.torproject.org/torperf.html) If you also use Bisq2, you might have noticed that the situation is not as bad there. The difference lies, among other things, in the additional data traffic that Bisq1 has, namely bitcoin nodes connections, and seednodes connections, and while the latter is less degraded, some users are report… ---
**Author:** ![suddenwhipvapor](https://bisq.community/user_avatar/bisq.community/suddenwhipvapor/32/3291_2.png) [@suddenwhipvapor](https://bisq.community/u/suddenwhipvapor)\ **Post date:** [June 16, 2024, 10:12am UTC](https://bisq.community/t/temporary-solution-for-dao-resync-loop/12016/3 "2024-06-16T10:12:29Z")
# UPDATE Currently, those who updated to bisq 1.9.16 to solve the DAO issue, could have new issues with DAO sync again, so the advised solution is to go back to 1.9.15, as the issues there have been fixed in the meantime. Make sure you delete the `version` file in the root of the data directory to be able to downgrade.