Stuck on 3/4 Hidden Service Published V9.3

Hello,
Under Mac OS, there is a bisq.log file at /Users/username/Library/Application Support/Bisq
You can either post the last lines here (there should be no personal info in the log, but please verify however before posting),
Or send me this log file so I could have a look (send me a PM).

This should help us to understand what is happening.

Sent you a PM.

ok, I’ll have a look.

Having an issue like this now on two Ubuntu boxes. 18.04 and 18.10 - Any advice or a solution would be welcomed.

i am getting this issue randomly here and there as well

cannot really tell what the problem ist. always connecting through VPN
but the issue seems to happen very randomly. then i close and after rebooot it might work or might not

Having a similar issue with Bisq 0.9.3 on Tails 3.10.1.

To enable Bisq to use the platform native Tor 0.3.4.8, I have inserted an iptables rule allowing localhost access to port 9052, copied the Tor authcookie to a readable location and finally, started Bisq with --torControlPort=9052 and --torControlCookie=control.authcookie

Everything appears to start up OK initially, but does not progress past step 3/4, specifically:

  • bitcoin peers get connected and wallet gets synchronized with mainnet
  • hidden service gets published
  • I get a healthy amount of outbound P2P peers, with roundtrips under 5000ms
  • I get 1-2 inbound connections to the onion service as well, with traffic flowing in both directions
  • can see the orderbook and past trades
  • can see the exchange rate

However, some things don’t work as intended, ultimately resulting in complete unusability:

  • “create new offer” fails with “no arbitrators available
  • in one singular case when I was allowed to create an offer, publishing the offer failed with “You need to wait until you are fully connected to the network. That might take up to about 2 minutes at startup” (not the case, it was more than 6 hours from Bisq startup)

Can anyone please help?

Happy to answer any questions or requests for diagnostic information.

@grace ,
Bisq’s next release (v0.9.4) will be available in the very next days.
Some things have been changed/improved concerning Tor usage.
So, I suggest you wait this next release and redo your tests. We’ll then see if the mentioned issues are still present.
(As far as I remember, each time a user mentions using Bisq on Tails … there are issues)

@Homard, thanks for your message. I have bad news and good news.

The bad news is that the upgrade to 0.9.4 hasn’t made any difference in the problem reported above. If anything, the “exchange. decentralized” splash seems to stay on screen longer than before. But there’s no progress past step 3/4 even after 24h of waiting.

Does anyone know what step 4 of 4 is, and what it needs to complete?

The good news is that I’m still here and happy to help with any information that you guys may find useful.

Tails is Debian (a fully supported platform) with a slightly more adversarial set of config defaults. Shouldn’t cause any showstopper issues. Also, I notice similar reports from OSX and Ubuntu users in this thread so it seems it’s not a Tails-only issue.

It would be great if issue was created on GitHub for this or mentioned to devs in Slack.

On a closer look at the logs, it appears that my test installation has a stubborn inability to open and maintain even one connection to seed nodes (no problem opening and receiving connections to regular peers, only seeds are affected). The “3/4” problem and also the “arbitrators” warning might be related to this.

Thanks for the suggestion, unfortunately I’m not on either of these services (not a software developer).

1 Like

Thanks for the return @grace .
That seems a bit strange, regular peers and seednodes are both onions.
Why connection issues with seednodes and not with P2P nodes ?

If we could have a look at the concerned part of the logfile, it would be nice.

… I ping Gandalf @ManfredKarrer :wink:

If I were to make an uneducated guess based solely on external observations, it could be a combination of a two factors:

  • different network traffic patterns between seeds and peers
  • my crappy broadband connection.

If this doesn’t seem to make any sense, then it probably doesn’t. :slight_smile:

I have TWO log fragments for you, which I hope will help to corner the problem. Apologies for the wall.

The first one is from a working installation:

Feb-26 04:37:37.908 [JavaFX Application Thread] INFO b.n.p.p.g.RequestDataHandler: We send a PreliminaryGetDataRequest to peer fl3mmribyxgrv63c.onion:8000.
Feb-26 04:37:51.993 [JavaFX Application Thread] INFO b.n.p.p.g.RequestDataHandler:
#################################################################
Connected to node: fl3mmribyxgrv63c.onion:8000
Received 540 instances
Filter: 1
MailboxStoragePayload: 276
Alert: 1
Arbitrator: 2
OfferPayload: 260
#################################################################
Feb-26 04:37:55.392 [JavaFX Application Thread] INFO b.n.p.p.g.RequestDataHandler: Start processing 0 items.

The second fragment is from my non-working “3/4” installation:

Feb-26 12:16:38.651 [JavaFX Application Thread] INFO b.n.p.p.g.RequestDataHandler: We send a PreliminaryGetDataRequest to peer fl3mmribyxgrv63c.onion:8000.
Feb-26 12:17:38.555 [JavaFX Application Thread] WARN b.n.p.p.g.RequestDataManager: We have started already a requestDataHandshake to peer. nodeAddress=fl3mmribyxgrv63c.onion:8000
Feb-26 12:17:38.652 [JavaFX Application Thread] INFO b.n.p.p.g.RequestDataHandler: A timeout occurred at sending getDataRequest:PreliminaryGetDataRequest(supportedCapabilities=[0, 1, 2, 7]) on nodeAddress:fl3mmribyxgrv63c.onion:8000
Feb-26 12:18:44.754 [InputHandler-fl3mmribyxgrv63c.onion:8000] INFO b.n.p.n.Connection$SharedModel: Shut down caused by exception java.net.SocketTimeoutException: Read timed out on connection=Connection{peerAddress=Optional[fl3mmribyxgrv63c.onion:8000], peerType=SEED_NODE, uid=‘1c112047-32de-4631-93e9-5c6a175a30ee’}
Feb-26 12:18:44.774 [JavaFX Application Thread] INFO b.n.p.p.PeerManager: onDisconnect called: nodeAddress=Optional[fl3mmribyxgrv63c.onion:8000], closeConnectionReason=CloseConnectionReason{sendCloseMessage=false, isIntended=false} SOCKET_TIMEOUT
Feb-26 12:18:44.822 [JavaFX Application Thread] INFO b.n.p.p.p.PeerExchangeManager: onDisconnect closeConnectionReason=CloseConnectionReason{sendCloseMessage=false, isIntended=false} SOCKET_TIMEOUT, nodeAddressOpt=Optional[fl3mmribyxgrv63c.onion:8000]

The same failure pattern is repeated in the log several times, however the “connected to node” message and item summary (as shown in the first example) never happen on the test installation. Only timeouts and other errors.

However, the normal peer connections don’t seem to be similarly affected, or at least not in a significant degree. Strange indeed.

@grace @NCKoeter @au_Bits @httphive
Sorry to hear about those issues. Can you please send me the log file (manfred@bitsquare.io). You can open it at Account/backup.

Could you try with an old bisq version? You would need to rename the current data directory to not overwrite the data there (might be incompatible with downgrade). Not sure if on Window its easy to downgrade, but make a backup just in case before doing it (e.g. de-installing will delete it!).
Maybe you can go back to 0.8.1 or so as we can be sure that its a different tor library version.

I will send the logfile after nexxt errors. Because I now again restarted with new data directory and some trades have worked. But it seemed there were 2 specific offers before that I would always get the errors.

It can be that there is a bug on the makers side if same offer fails or the makers computer is in sleep mode and network too slow to respond in time.

In the particular issue of “3/4”, downgrading to 0.8.1 made no difference in my case (problem persisted).
@ManfredKarrer, I have sent a log file, hope it helps.

Thanks! So it seems it is a local issue with eiter your onion address, provider, network connectivity or IP.
Can you try with a new data directory? You can pass --appName=Bisq_test so it will create a new wallet and onion address.
If that does not help, can you try a VPN or change your IP (e.g. by restarting your network divices or requesting from the provider a new one if its not a dynamic IP)?

@ManfredKarrer isn’t it --appDataDir=‘Bisq_test’ ?

Works as well. From appName the data dir gets derived.

1 Like