Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: create release branch for v0.15.3 #7017

Merged
merged 27 commits into from
Oct 14, 2022

Conversation

Roasbeef
Copy link
Member

kaloudis and others added 24 commits October 10, 2022 18:53
Lists with non-primitive members aren't supported in the query string of
a GET request with the current version of the grpc-gateway library. To
allow route_hints to be set through REST, we also offer a POST endpoint
for that call where the encoding of the request parameter can be
specified as JSON.
This fixes a bug where a caller would:
- call NotifyWhenOnline and pass in a channel
- the server's mutex is held and the pubStr is checked in peersByPub
- the peer object is in the peersByPub map
- the peer object has its quit channel closed
- QuitSignal is called in the select statement, and the function
  returns
- the caller is still waiting for the channel to be sent on forever
  since it was never sent on or added to the peerConnectedListeners
  slice.

This patch fixes the above bug by adding the channel to the
peerConnectedListeners slice if the QuitSignal select case is called.
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.
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.
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 lightningnetwork#6953
@Roasbeef Roasbeef added this to the v0.15.3 milestone Oct 11, 2022
@guggero
Copy link
Collaborator

guggero commented Oct 11, 2022

It looks like the commits from #6998 are missing. There's only the manual release notes fix.

Also, I noticed that the hints about the remote signing setup are mentioning upgrading to v0.15.2-beta directly, which should now be v0.15.3-beta. Going to create a PR to fix that, then we can include that as well.

@guggero
Copy link
Collaborator

guggero commented Oct 11, 2022

PR to include is here: #7018

Crypt-iQ and others added 2 commits October 13, 2022 12:57
This is so that if the funding transaction hasn't been confirmed
in 2016 blocks, the channel isn't marked as closed by the responder.
This commit bumps the recommended version to upgrade to for remote
signing setups.
@Roasbeef
Copy link
Member Author

Pushed up a new version with those two commits properly tacked on.

Copy link
Collaborator

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🎉

I assume we're not creating an RC on purpose?

@Roasbeef Roasbeef merged commit f674960 into lightningnetwork:v0-15-3-branch Oct 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants