Bootstrap using relay has failed

[rkfg]

Can't connect at all, tried via VPN and without it. This is shown with the GUI dialog box and in the log:

Bootstrap using relay has failed Future (compl/canc):true/false, FAILED, FutureBootstrap failed <-> Future (compl/canc):true/false, FAILED, You did not provide information where to bootstrap to. This could be also caused if you provided a peer address with a peer ID set to zero.

Full log: http://pastebin.com/cUBW6gwc

I've removed many repeating lines about "Seed testnet-seed.bitcoin.schildbach.de: failed to look up: org.bitcoinj.net.discovery.PeerDiscoveryException: java.net.UnknownHostException: testnet-seed.bitcoin.schildbach.de" and, preventing the question, this host is resolved ok for me using the host/nslookup utility so it's not on my end. I'm using openjdk-8-jdk and openjfx, Debian testing amd64.

[rkfg]

Could also be related, after the fresh start (removed ~/.local/share/Bitsquare) it updated itself and after clicking restart I've got this:

java.lang.IllegalStateException: App install dir didn't look like what we expected: [/run, /tmp, /opt, /emul, /srv, /sys, /media, /lib, /mnt, /var, /lost+found, /boot, /dev, /libx32, /etc, /usr, /proc, /lib32, /lib64, /bin, /root, /sbin, /home] vs []
    at com.vinumeris.updatefx.UpdateFX.findAppExecutable(UpdateFX.java:104)
    at com.vinumeris.updatefx.UpdateFX.restartApp(UpdateFX.java:67)
    at io.bitsquare.app.gui.UpdateProcess.restart(UpdateProcess.java:87)
    at io.bitsquare.gui.main.MainViewModel.restart(MainViewModel.java:148)
    at io.bitsquare.gui.main.MainView.lambda$createSplashScreen$314(MainView.java:290)
    at io.bitsquare.gui.main.MainView$$Lambda$99/1863885196.handle(Unknown Source)
    at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
    at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
    at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
    at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
    at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
    at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
    at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
    at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
    at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
    at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
    at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
    at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
    at javafx.event.Event.fireEvent(Event.java:198)
    at javafx.scene.Node.fireEvent(Node.java:8390)
    at javafx.scene.control.Button.fire(Button.java:185)
    at com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:182)
    at com.sun.javafx.scene.control.skin.BehaviorSkinBase$1.handle(BehaviorSkinBase.java:96)
    at com.sun.javafx.scene.control.skin.BehaviorSkinBase$1.handle(BehaviorSkinBase.java:89)
    at com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218)
    at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
    at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
    at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
    at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
    at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
    at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
    at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
    at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
    at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
    at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
    at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
    at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
    at javafx.event.Event.fireEvent(Event.java:198)
    at javafx.scene.Scene$MouseHandler.process(Scene.java:3758)
    at javafx.scene.Scene$MouseHandler.access$1500(Scene.java:3486)
    at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1762)
    at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2495)
    at com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:350)
    at com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:275)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$350(GlassViewEventHandler.java:385)
    at com.sun.javafx.tk.quantum.GlassViewEventHandler$$Lambda$227/1186900137.get(Unknown Source)
    at com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:404)
    at com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:384)
    at com.sun.glass.ui.View.handleMouseEvent(View.java:555)
    at com.sun.glass.ui.View.notifyMouse(View.java:927)
    at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
    at com.sun.glass.ui.gtk.GtkApplication.lambda$null$48(GtkApplication.java:139)
    at com.sun.glass.ui.gtk.GtkApplication$$Lambda$45/816110593.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)

I've actually downloaded the jar from the releases page, put it to /tmp and ran from there. Is it wrong? I don't want to install .deb just to try it out.

[ManfredKarrer]

The server where the bootstrap nodes are running has been migrated a few days ago and I have not restarted them. Now the bootstrap node is running again. The issue with the UpdateFX might be when you rung it as jar file, but thats nothing critical it just ignores to check for updates. Hope it works now for you.

[ManfredKarrer]

The error msg (19:41:39.760 [PeerGroup Thread] WARN o.b.n.d.MultiplexingDiscovery - Seed testnet-seed.bitcoin.schildbach.de: failed to look up: org.bitcoinj.net.discovery.PeerDiscoveryException: java.net.UnknownHostException: testnet-seed.bitcoin.schildbach.de ) is strange, never saw that. Maybe its related to the older version of BitoinJ used in that build? If you build from source default is regtest mode, so you need to have a local Bitcoin core in regtest mode running. In about 2 weeks I will release new binaries and update the docs. Was a bit busy with other things lately...

[rkfg]

Yes, it's working now. However, for the first time after it updates and I restart the program it fails for some reason to connect: Log: http://pastebin.com/JKhZ3P1D (I've removed all the lines about lookup failures)

After closing it and starting again it seems to be working fine and finally show the main GUI. I also don't see these lookup failures in the log. It's all reproducible with removing the said data directory, the lookup failures are back as well as that strange message from the screenshot. Hopefully the new build will work out of the box. I tried to build from source but either I'm doing something wrong or the build page is outdated as there's no core/target/shaded.jar. There's one in gui/target but it's probably incomplete as I couldn't run it due to a missing class, namely:

java.lang.ClassNotFoundException: io.bitsquare.app.BitsquareAppMain
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381) ~[na:1.8.0_45-internal]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_45-internal]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[na:1.8.0_45-internal]
    at java.lang.Class.forName0(Native Method) ~[na:1.8.0_45-internal]
    at java.lang.Class.forName(Class.java:348) ~[na:1.8.0_45-internal]
    at com.vinumeris.updatefx.UpdateFX.invoke(UpdateFX.java:112) ~[shaded.jar:na]
    at com.vinumeris.updatefx.UpdateFX.bootstrap(UpdateFX.java:36) ~[shaded.jar:na]
    at io.bitsquare.app.BitsquareAppMain.main(BitsquareAppMain.java:78) [shaded.jar:na]
Exception in thread "main" java.lang.RuntimeException: java.lang.ClassNotFoundException: io.bitsquare.app.BitsquareAppMain
    at com.vinumeris.updatefx.UpdateFX.bootstrap(UpdateFX.java:39)
    at io.bitsquare.app.BitsquareAppMain.main(BitsquareAppMain.java:78)
Caused by: java.lang.ClassNotFoundException: io.bitsquare.app.BitsquareAppMain
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:348)
    at com.vinumeris.updatefx.UpdateFX.invoke(UpdateFX.java:112)
    at com.vinumeris.updatefx.UpdateFX.bootstrap(UpdateFX.java:36)
    ... 1 more

Well, this is really unrelated to the bug I reported, sorry.

[ManfredKarrer]

Maybe the timeout was too tight set in that version for connection to the testnet.

There was a failed test from recent changes. I removed that class as it was outdated anyway and pushed a few min. ago.

Yes the current app is built from the gui module. You need to delete the data dir as there is the older verison loading a jar file which is not compatible with the current version (by UpdateFX). I just tested it and it works for me (after data dir deleted). jar is: gui/target/shaded.jar

[ManfredKarrer]

Upps... resources have been missing, pom is pushed now. (I run normally from IntelliJ so was not bothered by those build issues)

[ManfredKarrer]

Please note for that verison you need regtest locally running and the UpdateFX displays a failure which is fine as the update info data loaded from the server are not compatible with the current build (will fit again after I release new binaries)

[rkfg]

Yep, the test was failing so I compiled with -DskipTests. After removing the data directory the built version runs. Unfortunately, it now displays the connection error AFTER showing the gui after which it closes. No matter how many times I run it, even if I run it with --bitcoin.network=regtest

02:01:55.051 [JavaFX Application Thread] TRACE io.bitsquare.btc.WalletService - onPeerDisconnected 0 
02:01:56.615 [JavaFX Application Thread] TRACE io.bitsquare.btc.WalletService - onPeerDisconnected 0 
02:02:06.679 [NioClientManager] WARN  org.bitcoinj.net.NioClientManager - Failed to connect with exception: java.net.ConnectException: Connection refused 
02:02:06.679 [JavaFX Application Thread] TRACE io.bitsquare.btc.WalletService - onPeerDisconnected 0 
02:02:06.679 [NioClientManager] WARN  org.bitcoinj.net.NioClientManager - Failed to connect with exception: java.net.ConnectException: Connection refused 
02:02:06.679 [NioClientManager] WARN  org.bitcoinj.net.NioClientManager - Failed to connect with exception: java.net.ConnectException: Connection refused 
02:02:06.679 [JavaFX Application Thread] TRACE io.bitsquare.btc.WalletService - onPeerDisconnected 0 
02:02:06.680 [JavaFX Application Thread] TRACE io.bitsquare.btc.WalletService - onPeerDisconnected 0 
02:02:11.616 [JavaFX Application Thread] TRACE io.bitsquare.btc.WalletService - onPeerDisconnected 0 
02:02:11.616 [JavaFX Application Thread] TRACE io.bitsquare.btc.WalletService - onPeerDisconnected 0 
02:02:11.616 [JavaFX Application Thread] TRACE io.bitsquare.btc.WalletService - onPeerDisconnected 0 
02:02:19.526 [JavaFX Application Thread] TRACE io.bitsquare.gui.main.MainViewModel - Timeout reached 
02:02:26.991 [JavaFX Application Thread] TRACE io.bitsquare.BitsquareModule - doClose TradeModule 
02:02:26.991 [JavaFX Application Thread] TRACE io.bitsquare.BitsquareModule - doClose CryptoModule 
02:02:26.991 [JavaFX Application Thread] TRACE io.bitsquare.BitsquareModule - doClose TomP2PArbitratorModule 
02:02:26.991 [JavaFX Application Thread] TRACE io.bitsquare.trade.offer.OfferModule - doClose TomP2POfferModule 
02:02:26.991 [JavaFX Application Thread] DEBUG i.b.trade.offer.OpenOfferManager - shutDown 
02:02:26.992 [JavaFX Application Thread] TRACE io.bitsquare.p2p.tomp2p.TomP2PModule - doClose TomP2PModule 
02:02:27.026 [JavaFX Application Thread] TRACE io.bitsquare.btc.BitcoinModule - doClose BitcoinModule 
02:02:27.027 [JavaFX Application Thread] TRACE io.bitsquare.BitsquareModule - doClose GuiModule 
02:02:27.027 [JavaFX Application Thread] TRACE io.bitsquare.app.BitsquareAppModule - doClose BitsquareAppModule 

Is there a way to test the program in the real net, no matter testne or, well, real-realnet? Not regtest, I mean. For now I don't see anything in the windows, no exchange offers etc. I suppose there should be some.

[ManfredKarrer]

Do you have Bitcoin core in regtest mode running? If you like to test with testnet just use --bitcoin.network=testnet. Mainnet should alos work, though I have not tested with it for ages. If you switch networks you need to delete data dir as well (or just the wallet)

[ManfredKarrer]

Btw: I am on IRC @freenode #bitsquare

[rkfg]

Running with --bitcoin.network=testnet all the same error: It downloads some blocks almost up to 100% but then shows this error. Why?

And about IRC, it's my personal opinion but I believe it's true: never move a public bug/issue/whatever discussion to a private non-googleable place (and even if IRC logs may be stored and indexed somewhere, reading them could be pretty painful because of their size and noisiness). People could find this issue later because they've got stuck as myself. I perfectly understand the outrage they would feel if the discussion abruptly ends in "ok, let's solve it at IRC" or "I've sent the solution to your e-mail". So let it be here for everyone.

[ManfredKarrer]

Hm, thats strange, just started again with testnet and all works fine. I am on OSX, will check tomorrow on my Ubuntu box, need some sleep now :-)

[rkfg]

It connects now though it still spams the log with 11:09:40.508 [PeerGroup Thread] WARN o.b.n.d.MultiplexingDiscovery - Seed testnet-seed.bitcoin.schildbach.de: failed to look up: org.bitcoinj.net.discovery.PeerDiscoveryException: java.net.UnknownHostException: testnet-seed.bitcoin.schildbach.de

It also says "Connected with relay node |||| 2 peers" while before there was only 1 peer. Probably there were no relay peers available.

[rkfg]

Interesting: if I do dig testnet-seed.bitcoin.schildbach.de, once in a while it returns servfail.

I removed the data directory once again and got the connection error once again. Could it be a race condition between blocks downloading and p2p connection? It always seem to happen at 80-85% of blockchain and never happens after it has downloaded it.

[ManfredKarrer]

Seems the timeout is too tight (30 sec) and the schildbach seed has connection problems. I changed the timeout to 1 min. and added more logs. Could you try again after pulling the changes? Thanks!

[rkfg]

Right from the start. GUI doesn't show up. The log at ~/.local/share/Bitsquare/bitsquare.log is empty though it writes a lot to stdout: http://pastebin.com/s8s2LUat

[rkfg]

BTW, why do you have the blockchain sync timeout at all? Does it scale and what purpose does it serve? The blockchain could grow quite a bit and the connection speed might be slow so it could take several minutes or even hours to fully sync.

[ManfredKarrer]

Sorry for the late reply, I am not much online this week... Strange that the log is empty, when I run it form IntelliJ the log gets written. Yes you are right, the way how the timeout was set was wrong. I just changed it to be only used until I get any download progress.

[ManfredKarrer]

The bootstrap node was crashed, need to investigate why.... I restarted it, so the P2P network should work again.

[rkfg]

The log could be buffered and not flushed or something like this. I strongly suggest to make a clean test from time to time, IDEs tend to override some settings for common libraries like log4j. You can actually get one result when run the program from IDE and something completely different when run it standalone. Being a Java programmer myself I had some weird behavior examples in my work because of this.

So, back to the topic. The connection error is gone, hopefully for good. The log is still empty. My files look like this:

[~/.local/share/Bitsquare]> ls -lart
total 672
-rw-r--r--   1 rkfg rkfg      0 May  5 00:52 bitsquare.log
drwxrwx---+ 67 rkfg rkfg   4096 May  5 00:52 ..
drwxr-xr-x   2 rkfg rkfg   4096 May  5 00:52 keys
drwxr-xr-x   2 rkfg rkfg   4096 May  5 00:52 tmp
drwxr-xr-x   2 rkfg rkfg   4096 May  5 00:52 db
-rw-r--r--   1 rkfg rkfg  23488 May  5 00:53 Bitsquare.wallet
drwxr-xr-x   5 rkfg rkfg   4096 May  5 00:53 .
-rw-r--r--   1 rkfg rkfg 641024 May  5 00:54 Bitsquare.spvchain

I'm not familiar with logback but I don't see any mentions of the logfile there (gui/src/main/resources/logback.xml), only the console appender. The log was working when I used the release version with the update. It's pretty dated though.

[ManfredKarrer]

The log is configured in a java class (Logging) as I use the path to the data dir (data dir can be overridden by command line args, so xml does not work here). In the release verison I used a different solution. Maybe its some write access problems from logback? Nasty stuff...

[rkfg]

The error is back. After I synced the blockchain and restarted the program I have that timeout. Probably because there's nothing to sync now so it waits 1 minute and then shows that message. Also, on the second clean run (just now) I've got this:

Logback write access is hardly an issue as all other files are created.

[ManfredKarrer]

The bootstrap node is running, but in the logs I see a few timeouts. Those connection drops should recover by itself. The error you get is probably a bit too restrictive (I listen to the peermap and if there is no other peer there you get that, whcih means you lost connection to the P2P network). I will deactivate that error msg for now and change the behaviour to swallow connection drops for a certain time. The change is pushed. Thanks a lot for your patience with testing!

[ManfredKarrer]

Do you have a stable internet connection? I will update the bootstrap nodes now and restart them, so you get kicked out of a minute....

[ManfredKarrer]

They are online again...

[rkfg]

Can't connect to the bitcoin network, it doesn't even start downloading the blockchain and then shows the old good message about the port. I think this behavior is incorrect. All these errors could be temporary, the program should not just close under any circumstances except it has encountered a critical error like data corruption. It should silently reconnect again and again, no matter how much time it requires. The timeout should be an indication that one particular attempt has failed but user should not be concerned about it especially in this annoying way. You may display a small non-modal message somewhere that connection takes longer than it should so the user may probably check their internet connection or just wait.

Of course, this is only my opinion. It's based on what I saw and what I expect from the P2P software. P2P is an unstable technology by definition (as opposed to the client-server model where server is a high-uptime entity), nodes may go offline and become back online and I've never seen this to be the reason for a program to just exit without options. Being unstable, P2P software also usually behaves pretty aggressive finding peers. I think it's one of the reasons why your great work isn't known much though there's too few reviews out there as well. Users just run it, see the error, then the program exits. Meh, whatever. Let's try something else. This is very unjust as the idea and, I hope, the implementation are brilliant and really valuable to promote cryptocurrencies, make them more usable and easy for an average Joe.

Summarizing, these modal windows must be removed and the connection process must continue no matter what happens. Even if you couldn't setup UPnP mapping or a relay, there should be someone in the swarm with open ports so you'll communicate with it. Maybe not now, maybe 10 minutes later, but user should not restart the program to connect eventually.

Please, don't stop and develop it all further, this project should succeed!

[ManfredKarrer]

I just tested again and for me it connects without problems (I have a very fast and very stable internet connection). WHcih kind of connection do you have? You tested with VPN also right? I agree that the error handling is not good like it is at the moment. One reason I used that rough method to shut down is because weak connectivity will cause a lot of problems in the trade process, which can lead to losses of the offer fee. But you are right, that needs to be handled in a more user friendly way. The software is still under heavy development and a lot of the error handling is still missing, specially in the trade process. One other reason for the weak connectivity you experienced might be that atm there is only 1 bootstrap node. That will be changes as well as soon the app is more ready for testing to have at least 3 different servers with nodes running there.

Thanks a lot for your feedback, was a good input as I never got those connection problems but it made the obvious more clear that I need to cover those problems in a better way. If you have not lost completely your patience now :-), I would be happy if you can partizipate in the testing session with the new release once thats out (in a few weeks, will be announces in mailinglist and newsletter). That will still be not a usable version for trading but a test to see how stable the DHT network behaves and to get some user feedback. The Beta version ready for trading will need a few months more on development.

[rkfg]

I have 100/100 Mbit ethernet connection (FTTB, probably), it's pretty stable and almost always idling. And yep, it's not a link speed, it's my tariff plan, about $22/mo. I also use AirVPN for VPN connectivity to circumvent unjust site blocking and for other means. I have zero problems with testing software especially something as original and new as Bitsquare, ping me when it's ready! P2P with only a couple of nodes is a sad thing for sure, I used to join such projects when there's already several hundreds of nodes online. Thus even if they have such connection issues somewhere in the core, they never surface.

I was able to download the chain eventually by resetting the user data. Tested just before that and it was still connecting without visible progress until the error was thrown. After the chain was downloaded I restarted the program and while it all seemed fine (green marks and stuff) it dropped the connection error and exited. I believe that after rethinking and rewriting the error handling it will go away.

Good luck with your efforts, make it stable, make it easy to use and then you can bring a massive amount of users to your platform! A bit of publicity among cryptogeeks won't hurt I think. You can post periodic updates on your progress on btctalk and if you're persistent enough people will come to test and help. It's all about persistency after all, like transactions existing in the blockchain.

[ManfredKarrer]

Just removed the shut down behaviour. Will need more work with handling of connection repeat after failure, but that will be added a bit later. There will be soon some more community activity. I need to gather information about payment methods which are compatible with Bitsquare (low chargeback risk) and will probably start a thread on BTCTalk to find people helping on the investigation.

[ManfredKarrer]

I get now the same connection problems on my ubuntu VM box. There is a quite strange error msg I get (sounds like a sybil node): WARN org.bitcoinj.core.PeerSocketHandler - [195.154.81.170]:8333 - org.bitcoinj.core.ProtocolException: Peer does not have a copy of the block chain.

After that erro I get several: 18:02:06.624 [PeerGroup Thread] WARN o.b.n.d.MultiplexingDiscovery - Seed testnet-seed.bitcoin.schildbach.de: timed out 18:02:06.625 [PeerGroup Thread] WARN o.b.n.d.MultiplexingDiscovery - Seed testnet-seed.bitcoin.petertodd.org: timed out 18:02:06.625 [PeerGroup Thread] ERROR org.bitcoinj.core.PeerGroup - Peer discovery failure org.bitcoinj.net.discovery.PeerDiscoveryException: No peer discovery returned any results: check internet connection? at org.bitcoinj.net.discovery.MultiplexingDiscovery.getPeers(MultiplexingDiscovery.java:85) ~[1.jar:na]

Need to update to latest BitcoinJ master and debug on linux directly to see whats going on there. Mainnet works for me.

[meapistol]

I get similar problems and supply an image of the screen. I removed $HOME/Library/Application Support/Bitsquare and installed the new version which then worked and found about 4-5 peers. I restarted the computer due to a slow internet connection and a long time since the last reboot. I did not shutdown Bitsquare I think. After restart Bitsquare did not connect. I then removed $HOME/Library/Application Support/Bitsquare again and reinstalled but Bitsquare continues to not find its peers.

[ManfredKarrer]

@rkfg: I raised the issue with the Bitcoin testnet connection problems on the BitcoinJ mailing list: https://groups.google.com/forum/#!topic/bitcoinj/1dRPpvH0VsQ I fear it might take a bit to get that resolved. If you run a local Bitcoin core node in testnet (which you need anyway when testing a trade) then the connection should work (via that node).

The other issues should be resolved in the upcoming release (here is a preview I share with a small test group: https://bitsquare.io/updateFX/v03/bitsquare-0.3.1.deb -> will be published on Github the next days if there are no issues).

[rkfg]

Compiled from the latest commit, LGTM. No errors, blocks were downloaded etc. Good job! Now I need to milk a faucet for some testnet coins and test the app.

The only little complaint is that those fancy popups look ugly if no compositing manager is running. You can see it in my previous comment, not a big deal but I'd like to be able to turn it off and fall back to the system default boxes. JavaFX may not have such a feature though.

[ManfredKarrer]

Ah good that it works now! Btw. You can also test with regtest mode and 2 local clients if you want (see: https://github.com/bitsquare/bitsquare/wiki/How-to-use-Bitsquare-with-regtest)

You mean the red rectangle around the popup? Which Linux are you using, Arch Linux? The Popups should be replaced anyway by something more lightweight later, but will have a look to it.

[rkfg]

No, the red rectangle is the Awesome WM's border for the active window. The problem is that windows have a white border around the shadows, compositing make this border transparent so it all looks good. But without compositing there can be no custom window shapes (as I understand it) so they're exactly rectangular as I showed in #341.

Well, back to the topic: it now connects indefinitely to the testnet:

After restarting it managed to connect pretty quick but before I waited for several minutes without any change. Probably because of this:

23:22:32.351 [NioClientManager] WARN  org.bitcoinj.core.AbstractBlockChain - Block does not connect: 00000000000057a5be98ba3fa86dfdd12ffc9e6b77a90592628957243653f1ab prev 000000000000b91fe401
216aafd5ff982978eb63e2d4bb707aa7fd4c4fff3661

[ManfredKarrer]

Ah ok. Maybe I can reuqest form the system if it has the compositing manager running and dont use effects than. Yes that problem with the testnet sync I posted on BitcoinJ mailinglist already. I saw it always from time to time, and on my Ubuntu VM I cannot connect at all, though mainnet works. Seems that its related to IPv6 and the fallback might not work correctly.

[rkfg]

Forgot to tell about my system, I'm on Debian testing amd64 + Awesome WM, no DE and stuff. I started preferring as simple systems as possible without clunky subsystems like DEs like to bring with themselves. They break too easily and too often from my experience.

[ManfredKarrer]

Closed as related to TomP2P which is not used anymore.