In theory, it should be only one custom account with a given name. However,
users could have created custom accounts with various key scopes. In that case,
'LookupAccount' has a non deterministic behaviour. To fix that, we browse
through all key scopes (deterministically) and return the first account we found.
In theory, it should be only one custom account with a given name. However,
due to a lack of check, users could have created custom accounts with various
key scopes. In that case, ListAccounts has to list all these accounts.
In this commit we add support for two more custom parameters in the
main entrypoint for the `lnd` Docker image script (`start-lnd.sh`)
The two parameters are:
* RPCHOST to set a custom endpoint for the RPC server
* RPCCRTPATH to set a custom location for the certificate used when
communicating with the RPC server
Verify that the addresses we're decoding when sending coins onchain are
for the correct network. Without this check we'll convert the users
addresses to their equivalent on other networks, which is a gross
violation of the principle of least astonishment.
This change allows users to customize the gRPC keepalive settings. The
server ping values configure when the server sends out a ping by itself
and how quickly the client is expected to respond.
The client ping min wait configures the minimum time a client has to
wait before sending another ping. A connection might be closed by the
server if a client pings more frequently than the allowed min wait time.
We choose lower default values than the gRPC library used before:
- ServerPingTime: 1 minute instead of 2 hours
- ClientPingMinWait: 5 seconds instead of 5 minutes
This should by itself already make long-standing gRPC streams more
stable but also allow clients to set a custom client ping time of 5
seconds or more (a value of slightly more than 5000 milliseconds should
be chosen to avoid the server disconnecting due to slight timing skews).
By defining the full name for the docker image we avoid the issue that
occurs when using `podman` (tested on Fedora 38) where podman will prompt the
user for what docker repository to pull the image from.
In this commit, we eliminate some code duplication by removing the old
`HashMutex` struct as it just duplicates all the code with a different
type (uint64 and hash). We then make the main Mutex struct take a type
param, so the key can be parametrized when the struct is instantiated.
Test AddressIterator for the absence of panics, nil addresses, and empty
lists.
This fuzz test finds https://github.com/lightningnetwork/lnd/issues/7552
in seconds. No other panics found after 300+ CPU-hours of fuzzing.
In this commit, we attempt to fix an issue that may lead to force closes due
to small value HTLCs. The sweeper has built in a "negative yield" heuristic
where it won't sweep something that'll result in paying more fees than the
HTLC amount. However for HTLCs, we want to always sweep them, as we don't
cancel back the HTLCs before the outgoing contract is fully resolved.
In the future, we'll start to make more uneconomical decisions about if we
should go to chain at all for small value HTLCs, and also do things like
cancel back early if the HTLC is small and we think we might be contested by
chain fees.
This refactor aims to house the CalculateFeeRate function in a more
"shareable" location. It used to be a non-exported function inside
of rpcserver.go. However, other routines, such as FundPsbt inside
of walletkit_server.go, could also rely on the same fee calculation
functionality. So we move the function to rpc_utils.go and export it,
and we will reuse it in the FundPsbt workflow in a future PR.
This ensures that for transactions where a fee rate is specified
(instead of a confirmation target), lnd doesn't accept transactions
which would be ultimately ignored by the underlying chain's RPC.
In this commit, we add a new LinkFailureDisconnect action that'll be
used if we detect that the remote party hasn't sent a revoke and ack
when it actually should.
Before this commit, we would log our action, tear down the link, but
then not actually force a connection recycle, as we assumed that if the
TCP connection was actually stale, then the read/write timeout would
expire.
In practice this doesn't always seem to be the case, so we make a strong
action here to actually force a disconnection in hopes that either side
will reconnect and keep the good times rollin' 🕺.
