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 
If I were to make an uneducated guess based solely on external observations, it could be a combination of a two factors:
If this doesn’t seem to make any sense, then it probably doesn’t. 
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:8000=fl3mmribyxgrv63c.onion
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)?
Works as well. From appName the data dir gets derived.
Hi @grace,
I am now onto investigating Bisq on Tor (also https://github.com/bisq-network/bisq/issues/2278). thanks for the information thus far.
If I find anything, I will let you know.
Hi @freimair, thanks for looking into this. Just to establish a baseline of things that have already been tried:
Also, as pointed out in the github issue, running Bisq straight on Tails is not possible; some configuration changes are required to enable it. At a minimum, I found that the following are needed:
sudo iptables -I OUTPUT -o lo -p tcp -j ACCEPTsudo cp -f /var/run/tor/control.authcookie /home/amnesia/.local/share/After this, Bisq can be run as unprivileged user amnesia:
/opt/Bisq/Bisq --torControlPort=9052 --torControlCookieFile=/home/amnesia/.local/share/control.authcookie
I have sent @ManfredKarrer a copy of my Bisq debug log, can send it to you too if you’re interested.
Hi @grace ,
What is the type of you connection ? wifi ?
How is your IP ? fix or dynamic ?
If the question are too indiscreet, please ignore (or answer by PM).
@Homard,
My connection is rural-grade ADSL, decent downlink (1-1.5Mb/s) with slow uplink (150-200kb/s). There is no firewall or UPNP running on my router, no restrictions ISP-side either. WAN IP is dynamic.
LAN is a private subnet with NAT. Bisq+Tails computer connected via WiFi or Ethernet. There is no significant difference between the two, since ADSL is always the bottleneck.
The same setup has been used successfully to test other peer-to-peer software in the Tails environment, such as OpenBazaar, Bitmessage and Lightning Labs LND, which all worked well (one at a time). 
I hope this gives you an idea.
Hi @freimair, thanks for the update. Unfortunately this doesn’t solve my problem, which was not Tails-related to start. As per above, I am already using a workaround very similar to the one discussed in issue 2278.
My problem, which I suspect affects several posters in this thread (also Github issue 2474) and is not Tails-specific, is about Bisq’s failure to bootstrap correctly under degraded network conditions due to an inability to handshake reliably with seed nodes.
I have some new information about the issue and will open a new topic shortly, to avoid thread hijacking.