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.
We know that onion blobs in lightning are _exactly_ 1366 bytes in
lightning, but they are currently expressed as a byte slice in
channeldb's HTLC struct. Blobs are currently serialized as var bytes,
so we can take advantage of this known length and variable length
to add additional data to the inline serialization of our HTLCs, which
are otherwise not easily extensible (without creating a new bucket).
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' 🕺.
In this commit, we add a new LinkFailureAction enum to take over the old
force close bool. Force closing isn't the only thing we might want to do
when we decide to fail the link, so this is a prep refactoring for an
upcoming change.
It is best to have deterministic fuzz targets, so that if a failure
occurs, it can be easily reproduced.
This commit swaps the cryptographically secure RNG for a deterministic
one seeded from fuzzer input.
Move the functionality directly into completeHandshake instead. If a
failure does happen at any point during the handshake, it is beneficial
to know which line it happens on for debugging. The helper function was
hiding this information.
