This commits exposes the various parameters around going to chain and
accepting htlcs in a clear way.
In addition to this, it reverts those parameters to what they were
before the merge of commit d1076271456bdab1625ea6b52b93ca3e1bd9aed9.
This prevents a panic during test failure due to a child test calling
FailNow on a parent test context. The sub tests now capture the
testing.T object provided in each closure as opposed to ignoring it and
using the parent context.
In this commit, we add 4 new itests for exercising the SCB restore
process via 4 primary scenarios: recover from backup using RPC, recover
from file using RPC, recover channels during init/creation, recover
channels during unlock. With all fields populated there're a total of 24
new scenarios to cover. At the time of authoring of this commit, the
other scenarios (bits are: initiator, updates, private) have been left
out for now, as they increased the run time of the integration tests
significantly.
In this commit, we modify the core testDataLossProtection test to
extract the primary DLP assertion logic into a new function. We do this,
as the upcoming SCB tests will fallback to this test after some initial
set up.
In this commit, we update all uses of the `getChanPointFundingTxid` to
match the new function signature. We no longer need to convert to a
chainhash.Hash, as the method does so underneath now.
lnd_test: adding address validation for send coins
The commit adds a test that checks that when a user calls sendcoins, the
receiving address is validated according to the current network. If the
address is not compatible with the current network, it will return an
error to the user.
rpcserver: adding a check for compatible network in SendCoins
This commit adds a check in SendCoins that checks whether the receiving
address is compatible with the current network.
Fixes#2677.
This commit increase the expiry grace delta to a value above the
broadcast delta. This prevents htlcs from being accepted that would
immediately trigger a channel force close.
A correct delta is generated in server.go where there is access to
the broadcast delta and passed via the peer to the links.
Co-authored-by: Jim Posen <jim.posen@gmail.com>
In this commit, we lower the default CLTV delta from 144 (1 day) to 40
blocks (~7 hours). We do this as the initial value was purposefully very
high, and was only in place as place holder in earlier versions of the
software. Such a high value can also discourage path finding algorithms
from taking lnd paths due to the negative impact of CLTV value in widely
deployed heuristics.
Exposes the three parameters that dictate
the behavior of the channel status manager:
* --chan-enable-timeout
* --chan-disable-timeout
* --chan-status-sample-interval
Since the getChanInfo call would require the node to have only one
channel, it made no sense to check the number of channels after calling
it.
Instead we check it first, giving the node time to restart.
By mistake we were checking that only one transaction was in the mempool
when looking for the justice tx, which wasn't always the case, and would
make the test fail.
Because the integration tests are already long-running, it is preferable to
add testing for the RPC channel update subscription to an existing test rather
than adding additional tests.
In this commit, we extend the remote/receiver chain claim integration
test to assert that the on-disk representation of the invoice on the
receiving side (Carol) is marked as settled due to the claiming the HTLC
on-chain.
Since the chain backend and miner is now seperate nodes, the reorg test
must be slightly rewritten. We use the Btcd Node RPC to connect and
disconnect the three bitcoin nodes in question (chain backend, miner,
temp miner) to control the reorg scenario.
