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

Christoph Atteneder notifications at github.com
Mon Mar 23 14:57:35 UTC 2020

@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: []: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:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200323/e9677117/attachment.html>

More information about the bisq-github mailing list