-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Never ending "awaiting blocks" #2800
Comments
Similar problem here, I haven't been able to take a trade yet. It seems like the DOA never connects. I waited hours and even overnight. Here is what I see on the screen. I can post a trace as well if it's helpful. I'm using a TOR proxy, here the startup command: |
It's not exactly similar. In my case, the appli is stucked on step (3/4). |
I did that several times. I even tried rebuilding from master and the latest release. I can try building from an earlier release if you have one to suggest. Please let me know if posting the logs is useful. I can either post a full trace or filter it based on your recommendation. |
My small understanding is such issues are often related to the connection quality. |
That is an interesting assumption. I do have broadband internet. There must be some ways to validate this assumption by analyzing the logs. What class do you suggest that I trace? What do you figure it is trying to synchronize, the Bitcoin network or the Bisq order book with other peers? I disabled the DAO and still getting the same issue. This issue seems to occur only when using a SOCKS5 Tor proxy. |
There may be some issue with your tor usage. |
No luck after the upgrade. I have the exact same problem. Here is more info about my config: https://www.whonix.org/wiki/Bisq . Do you want some logs? |
See also discussion in Whonix forums: |
This should be fixed with #2821 |
Sometimes, for whichever reason, the synchronizing DAO step never ends.
The appli is stucked on "awaiting block" and it doesn't change, even waiting an hour.
Would it be interesting/possible that the appli itself takes notice of being stucked, and suggests restarting ?
It's noticeable that the appli correctly updates the number of the last block.
So the appli could see that the gap is only growing between the last verified block (stucked) and the growing number of blocks.
related (or maybe) to:
I catched this in the CLI:
The text was updated successfully, but these errors were encountered: