When we support the Milan protocol, we'll use a default port. But
for now, don't listen at all unless a port is specified.
Fixes: #54
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Added .travis.yml to get travis-ci to build and run tests for us.
In addition this fixes a flaky test due to the fact that when lightning2
connects to lightning3 and we tell lightning3 to restart, then
lightning2 will back-off its reconnection attempts, potentially causing
a timeout to trigger during tests. This was triggered by travis-ci
relatively consistently since the restart would take quite some
time. Now simply restarting them in reverse order and a small timeout
seems to fix this consistently.
This significantly reduces re-testing of the same paths, and simplifies
the addition of new tests.
make check -j12 times:
Before: 9m24.973s
After: 7m52.005s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's possible that we won't have sent the anchor, but state is
committed in db. And our current philosophy is that we retransmit all
the txs dumbly, all the time.
Our --restart --timeout-anchor test trigger this case, too, so
re-enable that now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Importantly, they're now entirely block driven. We don't use
dev-setmocktime at all any more.
This also fixes a bug if we run the test twice against the same
bitcoind; we need to extract the time from the block header rather
than assuming bitcoind is on the current time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means running 3 bitcoinds, which is slow enough to start on my laptop
that I need to increase the startup wait for 30 to 60 seconds, and similarly
the test.sh check loop.
Before: real 13m42.868s
After: real 8m19.563s (make -j3)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Waiting until lightningd is up is too long: do a --version test in setup,
and then check that all reported versions match later on.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We've seen intermittant failures on testnet, so disable sending feechanges
for now: we're completely changing it for 0.6 anyway, due to Milan Spec.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This gives much better errors, and allows us to return the peer id.
Closes: #37
Reported-by: Glenn Willen
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, remove fee ranges on testnet (too unreliable) and accept
a single confirm.
(Note that an earlier version of this had a bug when there was no
config file, this version includes the fix).
Closes: #40
Reported-by: Glenn Willen
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Firstly, we need to update the staging fee amount when we queue a change.
Secondly we need to remove completed fee updates, otherwise we hit a
database constraint that peer & state are unique.
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Three days of on and off debugging, before I realized my server was talking
to a non-testnet bitcoind. There was a bitcoind on that machine running
on testnet, but it uses the same dir and config, so the --bitcoin-datadir
option couldn't help.
This is more certain: specify whether we're testnet on every single query.
Now we can skip the attempt to parse bitcoin.conf, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
NO_VALGRIND= daemon/test/test.sh --normal --restart
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
This is expected: it happens when node3 is restarting. Redirect
errors to /dev/null.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rename the structs to match (and remove dev-echo).
This makes it clear that they're not the normal API.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need some way to reflect the tradeoff between the possible delay if
a payment gets stuck, and the fees charged by nodes. This adds a risk
factor which reflects the probability that a node goes down, and the
cost associated with losing access to our funds for a given time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, make sure B can just afford it, then have the A add a
HTLC which means B can no longer afford the fees, and A should cover
it.
We do this by modifying the previous overlapping-fail test, but we
need to have B offer it the htlc before A does: racy in the normal
autocommit case. So we do a manual commit here, always.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is less convenient to use, but makes far more sense for a real
user (like a wallet). It can ask about the route, then decide whether
to use it or not.
This will make even more sense once we add a parameter to control how
long we let the HTLC be delayed for, so a client can query for high,
medium and low tolerances and compare results.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We stopped automatically retransmitting locally-generated add/removes
after a reconnect, but this breaks the "pay" interface as it stands.
The correct solution to this is to make the pay interface idempotent:
you can trigger it as many times as you want and it will only succeed
once.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
Christian Decker