If a peer receives a channel reestablish message shortly after the
channel has been closed, it will resend its own channel reestablish
message. In the meantime the other peer could also have seen the channel
being closed and will also resend its own message. This leads to a
resend loop that never terminates.
To avoid two peers getting into this situation, we now allow only one
such resent message per conection.
If we are the initiator, we check that our starting balance after
subtracting fees are not less than two times the default dust limit.
This commit adds a similar check for the non-initiator case, checking
that the remote party has a starting balance of reasonable size.
We use the fact that we can tell whether the commit is local or remote
by inspecting the witness script. We cannot use the maturity delay
anymore, as we can have delayed to_remote outputs also now.
Co-authored-by: Joost Jager <joost.jager@gmail.com>
We also increase the witness size for these types to account for the 3
extra bytes. The size won't be correct in all cases, but it is just an
upper bound in any case.
To be able to change more than the witness used for each test case, we
extract commit and sweep tx generation into own methods that can be
called from each test case.
We do the same for TestHTLCReceiverSpendValidation
This fixes an error case that wouldn't have been caught, since
vm.Execute applies more rules than the individual steps (most notably
the clean stack rule).
Instead we execute the engine as normal, and only step through if we
decide that the outcome is unexpected.
Since we never attempt to sweep an HTLC we offered with the preimage on
the remote's commitment, we never use the constant
AcceptedHtlcSuccessWitnessSize for weight estimation. Similarly, we
never timout an HTLC offered by the remote on our own commitment, and
don't need the constant OfferedHtlcTimeoutWitnessSize.
To better distinguish payments from HTLCs, we rename the attempt info
struct to HTLCAttemptInfo. We also embed it into the HTLCAttempt struct,
to avoid having to duplicate this information.
The paymentID term is renamed to attemptID.
This fixes a race during channel closing, where the last channel state
update was still not finished when we set the channel close bit in the
database. This lead to a flake during integration tests, where the last
state update would not finish, and the channel wasn't closes
successfully.
We fix it by first unregistering the channel, making sure it is removed
fully from the link before doing the db modification.
Since our HTLC must also be added to the remote commitment, we do the
balance caluclation also from the remote chain perspective and report
our minimum balance from the two commit views as our available balance.
When we send non-dust HTLCs as the non-initiator, the remote party will
have to pay the extra commitment fee. To account for this we figure out
if they can afford paying this fee, if not we report that we only have
balance available for dust HTLCs, since these HTLCs won't increase the
commitment fee.
Since we want to handle the edge case where paying the HTLC fee would
take the initiator below the reserve, we move the subtraction of the
reserve into availableBalance where this calculation will be performed.
This commit adds an extra validation step when adding HTLCs. Previously
we would only validate the remote commitment resulting from adding an
HTLC, which in most cases is enough. However, there are situations where
the dustlimits are different, which could lead to the resulting remote
commitment from adding the HTLC being valid, but not the local
commitment.
Now we also validate the local commitment. A test to trigger the case is
added.
add
To ba able to validate the commitment sanity both for remote and local
commitments, and at the same time predict both our and their add, we let
validateCommitmentSanity take an extra payment descriptor to make this
possible.
The unit test TestNewBreachRetributionSkipsDustHtlcs triggered a state
transition from Bob, even though it was Alice that had added the HTLCs.
This is wrong since it will lead to Bob still owing Alice a commitment,
which is not accounted for in the unit tests.
We add a sanity check that the add heights has been set for all entries
found in the logs, and return an error otherwise. This won't happen
during normal operation, but it does reveal the mistake in the unit
test, which is fixed by making Alice trigger the transition.
In addition we resolve a long standing TODO by removing a (purposeful)
panic in the channel state machine. Old version of lnd had a bug that
could lead to the parent entries being lost during channel restore. A
panic was added to get to the bottom of if.
This is now fixed, so new nodes shouldn't encounter it. However, to be
on the safe side, instead of panicking we return an error back to
gracefully exit the channel state machine.
After renewing the certificate, the new certificate wasn't actually
loaded and used, causing the old one to be used until lnd was restarted.
This fixes that by reloading it after it has been written.
This commit makes lnd recreate its TLS certificate if the config's
tlsextradomains or tlsextraips changed. This is useful, since earlier
user would have to manually delete the files to trigger lnd to recreate
them.
To ensure users don't accidentally have their TLS certificate recreated,
we gate it behind a flag --tlsautorefresh that defaults to false.
This commit creates a new utility method IsOutdated that can be used to
check whether a TLS certificate mathces the extra IPs and domains given
in the lnd config.
Returning from the sendPayments method closes the underlying stream, so
we would risk payments still being in flight when returning.
We add the running goroutines to a waitgroup, such that we can wait for
them all to exit before exiting and closing the stream.
In case an error is encountered in the process, we will return directly,
which will close the `reqQuit` channel and prompt the gorpoutines to
shut down.
This commit fixes a problem that could arise when handling a continuous
stream of payIntents. We would risk the client sending a set of payment
intents and closing the stream, but we wouldn't be sure the sendLoop had
read all messages on the `payChan` before exiting with the nil error
from the `errChan`.
Instead, we close the `payChan` to indicate that no more payments are
going to be received.
This commit fixes a potential issue in the bidirectional sendPayment
case, where multiple goroutines could be sending on an errChan with
buffer 1. Instead we select on default as well, as it is enough to
handle the first error that was received.
Intead of checking for shutdown in the receive loop, we let the sendLoop
handle it, as it can return the error directly. This works since the
returning sendLoop will trigger a close of the `reqQuit` channel, which
will ensure the receive loop exits.
To ensure lnd is able to pick up an on-chain preimage properly after a
restart, we suspend Alice and check that the payment is listed correctly
as succeeded after a restart.
On both Android and iOS (when not using a simulator) the application
procees doesn't have write permissions to the default lnd directory.
This commit adds a note about using the app directory given by the used
platform.
The wallet unlocker service also requires the TLS certificates to be
added, but this was not set. This commit sets the options similar to
what is done for the regular RPC server.
Since spaces where trimmed only after checking for empty strings, an
empty flag '-- ' would be passed along to lnd. Intead we trim first to
properly ingore such flags.
Johan T. Halseth