In this commit, we modify the way we compute the starting ideal fee for
the co-op close transaction. Before thsi commit, channel.CalcFee was
used, which'll compute the fee based on the commitment transaction
itself, rathern than the co-op close transaction. As the co-op close
transaction is potentailly bigger (two P2TR outputs) than the commitment
transaction, this can cause us to under estimate the fee, which can
result in the fee rate being too low to propagate.
To remedy this, we now compute a fee estimate from scratch, based on the
delivery fees of the two parties.
We also add a bug fix in the chancloser unit tests that wasn't caught
due to loop variable shadowing.
The wallet import itest has been updated as well, since we'll now pay
600 extra saothis to close the channel, since we're accounting for the
added weight of the P2TR outputs.
Fixes#6953
In this PR, we introduce a new Github work flow tool that should help us
keep better track fo reviewer load across the proejct. Ideally this can
also be used as a tool to help new PRs find a reviewer, and also for us
to better balance out review load, and keep track of how long it takes
to do PR turnaround.
With this commit we prepare for adding multiple issue templates to
GitHub that will be shown when the user clicks on the "New Issue" button
on GitHub.
The config.yml will also add a bunch of useful links to the page that
shows the different issue templates.
An example of how this template selection page looks like can be found
here: https://github.com/lightninglabs/lightning-terminal/issues/new/choose
This commit adds a short guide that explains how a remote signing node
setup should be migrated from lnd v0.14.x-beta to lnd v0.15.x-beta and
adds a note to all 0.15.x release notes.
Previously, the Switch would not check waiting-close channels' fwdpkgs
for settles or fails to reforward. This could result in a force close
in a rare edge case if a restart occurred at the wrong time. Now,
waiting-close fwdpkgs are checked and the issue is avoided.
In order to reduce the number of calls to the db we try to process as
few channels as we can + try to not do extra work for each of them.
- First fetch all the channels. Then, filter all the public ones and
sort the potential candidates by remote balance.
- Filter out each potential candidate as soon as possible.
- Only check the alias if the channel supports scid aliases.
- Because we sort the channels by remote balance, we will hit the
target amount, if possible, as soon as we can.
We do not want to leak information about our remote balances, so we
shuffle the hop hints (the forced ones go always first) so the invoice
receiver does not know which channels have more balance than others.
It's possible that a user might not want the Tor private key to sit on the disk in plaintext (it is a private key after all). So this commit adds a new flag to encrypt the Tor private key on disk using the wallet's seed. When the --tor.encryptkey flag is used, LND will still write the Tor key to the same file, however it will now be encrypted intead of plaintext. This essentially uses the same method to encrypt the Tor private key as is used to encrypt the Static Channel Backup file.
The functions inside of the crypto.go file in chanbackup (like EncryptPayloadToWriter and DecryptPayloadFromReader) can be used by a lot of things outside of just the chanbackup package. We can't just reference them directly from the chanbackup package because it's likely that it would generate circular dependencies. Therefore we need to move these functions into their own package to be referenced by chanbackup and whatever new functionality that needs them
