Since https://github.com/lightningnetwork/lnd/pull/506, `defaultchanconfs` is nested under `bitcoin`. Using this parameter at the top level generates a warning message:
```
2018-03-17 23:07:08.273 [WRN] LTND: /home/bitcoin/.lnd/lnd.conf:7: unknown option: defaultchanconfs
```
and using it nested under `bitcoin` does not.
In this commit, fix the inability of some users to connect to the DNS
seed using our direct TCP fallback. We do this as some resolvers filter
out our large SRV requests due to their size (they also include public
keys). Instead, we’ll use a direct TCP resolution in this case.
However, after a recent change, we forgot the period at the end of the
target DNS host. This is an issue as the domain needs to be fully
qualified.
The fix is easy, add a period within our string formatting to target
the proper sub-domain and SRV target.
Fixes#854.
The port numbers used in the ZMQ examples are inconsistent between:
- The initial explanation of ZMQ
```
They must be combined in the same ZMQ socket
address (e.g. `--zmqpubrawblock=tcp://127.0.0.1:28332` and
`--zmqpubrawtx=tcp://127.0.0.1:28332`).
```
- The sample bitcoin.conf
```
zmqpubrawblock=tcp://127.0.0.1:18501
zmqpubrawtx=tcp://127.0.0.1:18501
```
- The lnd command-line example:
```
lnd --bitcoin.active --bitcoin.testnet --debuglevel=debug --bitcoin.node=bitcoind --bitcoind.rpcuser=REPLACEME --bitcoind.rpcpass=REPLACEME --bitcoind.zmqpath=tcp://127.0.0.1:28332 --externalip=X.X.X.X
```
I changed the sample bitcoin.conf port numbers to 28332 so they match the rest of the examples.
In this commit, we update the DNS bootstrapper to match the new query
semantics expected by the new DNS server. We no longer hard code the
target DNS host, and instead, we’ll re-use the same target endpoint as
we only need the soaShim in order to establish a direct TCP connection
for the queries.
This commit removes two unnecessary disconnect/reconnect attempts
from the switch itest. Both occur after the primary test has been
completed, and were being executed before doing a final sanity check
that the path is still usable. Nothing about the test behavior should
change.
This commits adds a complement to the existing WaitPredicate
helper function, ensuring that a boolean statement remains
true for the duration of the provided timeout. This expands
our ability to do simple sanity checks where the wait-until
semantics of WaitPredicate may not be as-well suited.
This commits removes many of the timeout-based consistency
checks, which tend to be less dependable on Travis. They
have been replaced with stronger WaitPredicates, and the new
WaitInvariant where appropriate. This should give provide a
much greater degree of reliability in our highly-variant
testing environments.
