Currenlty the maxHtlcs value is recomputed after receiving
accept_channel. This works when the derivation is deterministic, howver
we now allow the user to manually override this value from open_channel.
As such, we must retain the chosen value in memory throughout the
funding process, otherwise the initiator would revert to the
deterministic derivation and the two endpoints will disagree on the
correct max-htlcs value in their view of the other's policy.
The PR #4421 updated the cert package. To make lnd usable as dependency
in other projects after the PR was merged, we need to tag and update the
cert package.
Add a new health check package which will periodically poll health
check functions and shutdown if we do not succeed after our set number
of attempts. The first check that we add is one for our chain backend,
to ensure that we are connected to a bitcoin node.
This commit adds a shutdown logger which will send a request for
shutdown on critical errors. It uses the signal package to request safe
shutdown of the daemon. Since we init our logs in config validation,
we add a started channel to the signal package to prevent the case where
we have a critical log after the ShutdownLogger has started but before
the daemon has started listening for intercepts. In this case, we just
ignore the shutdown request.
The old key expires in a month or so. We recently updated the key to use
a newer expiry date. This commit updates the link to point to the
updated gist.
Previously whether or not to add test htlcs was implictly controlled by
a nil value of the HtlcDescs test parameter. With the conversion to
json, that nil value got lost.
The reason that the test still passed is because with the fee rate of
the no-htlc test case, the htlcs were trimmed. Also because in the test
json, balances are specified after applying htlcs, the test didn't fail
with a mismatching balance.
In this commit, we update our btcwallet dep to the latest version. This
version includes a bug fix for dust calculation. Without this bug fix,
users would potentially significantly overpay on fees, as dust was
computed using the desired fee of the transaction rather than the min
relay fee.
In this commit, we update the hop hint selection to account for the fact
that with MPP, a single payment may consume multiple channels. As is, if
a user only has two 0.5 BTC channels, and tries to make a 1 BTC channel,
then the current logic won't include any hop hints.
To solve this, we first add all the channels which in isolation can
carry the payment in question. We then do another pass that accumulates
channels until either we reach our hop-hint limit, or the total
bandwidth that we've accumulate is greater than 2x the payment amount.
In this commit, we make a new wrapper method around the internal
`WalletController` method to ensure it holds the coin select mutex while
the balance is being computed.
