[bisq-network/bisq] [WIP] Check BTC node config without IO overhead (#4081)

[Christoph Atteneder]

@dmos62 Your build is broken right now: https://travis-ci.org/github/bisq-network/bisq/builds/665235608?utm_source=github_status&utm_medium=notification

> a) connecting to a pruning node, on my setup at least, causes the connection to crash, and the listener never gets triggered; this is a rare BitcoinJ edge case bug and I opened an issue for it #4080 ;

Yes, I get following exception in the logs
```
März-23 15:46:57.444 [NioClientManager] WARN  o.b.core.PeerSocketHandler: [127.0.0.1]:18444 -  org.bitcoinj.core.ProtocolException: Received AlertMessage before version handshake is complete.
	at org.bitcoinj.core.Peer.processMessage(Peer.java:478)
	at org.bitcoinj.core.PeerSocketHandler.receiveBytes(PeerSocketHandler.java:184)
	at org.bitcoinj.net.ConnectionHandler.handleKey(ConnectionHandler.java:223)
	at org.bitcoinj.net.NioClientManager.handleKey(NioClientManager.java:86)
	at org.bitcoinj.net.NioClientManager.run(NioClientManager.java:122)
	at com.google.common.util.concurrent.AbstractExecutionThreadService$1$2.run(AbstractExecutionThreadService.java:66)
	at com.google.common.util.concurrent.Callables$4.run(Callables.java:122)
	at org.bitcoinj.utils.ContextPropagatingThreadFactory$1.run(ContextPropagatingThreadFactory.java:49)
	at java.base/java.lang.Thread.run(Thread.java:844)
```
> 
> and, b) this WIP implementation just does `peer.close()`, which causes the PeerGroup to just retry the connection, in case we're in local mode, or possibly retry later in case we're in non-local mode (didn't explore non-local behaviour yet); I'm pondering if this is indeed undesirable or if we would want to use this to get free auto-retry.

You mean a retry to the same peer?

> Another open question is what to do in case a remote node is found to be misconfigured. Just an error log?

It depends. If it would be a misconfigured provided node/public node I would just ignore it and not connect to it. If it is a node the user has configured by using a config/start parameter I think we should display a warning to the user. Also if it is a misconfigured local node we want to notify the user that something is not correct.

In general if we do this check after the connection I think it should be fine if we block the setup process at that point (e.g. when a local bitcoin node is misconfigured) and do it as with your previous implementation to allow the user to shutdown and fix this issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/4081#issuecomment-602651836
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200323/e9677117/attachment.html>