This commit removes the `peerport` and `rpcport` config options and
adds `listen`, `rpclisten`, and `restlisten` options to allow setting
one or multiple interfaces to listen on for incoming connections.
It also adds a `nolisten` option to allow disabling the listener for
incoming peer connections.
This commit factors out the btcd and ltcd options into their own sections
similar to neutrino, and adds a bitcoind section as well. Now, you specify
node options similarly to:
--ltcd.rpchost=...
or
--btcd.rpcuser=...
or
--bitcoind.zmqpath=...
For Bitcoin, you specify an alternate back-end to btcd as follows:
--bitcoin.node=bitcoind
or
--bitcoin.node=neutrino
You can also specify the default option:
--bitcoin.node=btcd
For Litecoin, only `btcd` mode is valid, and corresponds to the `ltcd`
section. For example:
--litecoin.node=btcd
--ltcd.rpchost=...
The new code also attempts to read the correct options and auth info
from bitcoin.conf just as it does from btcd.conf/ltcd.conf.
In this commit, we modify the CloseChannel to wait for both nodes to
detect that channel as being active before we attempt to close it. This
should serve to reduce many of the flakes that we’ve been seeing on
travis which were caused by node A detecting the channel as active, but
node B not, leading to a test flake under certain timing conditions.
The new function uses the recently added WaitPredicate method.
Recent changes to the funding manger’s state machine have resulted in
some additional database calls during the funding process. This has
slowed down the tests by a few ms here and there. Recent integration
test runs have begun to fail due to AssertChannelExists returning an
error as the channel hasn’t fully propagated yet. In order to remedy
this, we’ll now use WaitPredicate to poll repeatedly to ensure. This
should serve to reduce flakes encountered within the integration tests.
In this commit, we add a new helper function to the NetworkHarness
struct. This helper function serves to allow test authors to look up
pointer to an active node based on its current public key.
Each time a new node is started, its public key will be re-registered
within the global nodesByPub map.
