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

build: create v0.14.3 rc1 release branch #6366

Merged

Conversation

carlaKC and others added 30 commits March 24, 2022 16:14
Update SelectHopHints to return a set of hop hints that can be
converted to route hints / functional options by the caller. This
change allows external code to call SelectHopHints to get a set of
route hints and use them as it likes, rather than limiting the
return value to functional options for invoice creation.
In this commit, we add a new field to the WalletBalance call that
permits users to account for the set of outputs that may be locked due
to a pending transaction. Without this field any time users locked
outputs for things like PSBT signing, then they disappear from the
WalletBalance call, which may cause a panic.
…nflicts

Before this commit, we we were trying to sweep an anchor output, and
that output was spent by someone else (not the sweeper), then we would
report this back to the original resolver (allowing it to be cleaned
up), and also remove the set of inputs spent by that transaction from
the set we need to sweep.

However, it's possible that if a user is spending unconfirmed outputs,
then the wallet is holding onto an invalid transaction, as the outputs
that were used as inputs have been double spent elsewhere.

In this commit, we fix this issue by recursively removing all descendant
transactions of our past sweeps that have an intersecting input set as
the spending transaction. In cases where a user spent an unconfirmed
output to funding a channel, and that output was a descendant of the now
swept anchor output, the funds will now properly be marked as available.

Fixes lightningnetwork#6241
In this commit, we add a new integration tests to exercise the fix
introduced in the prior commit. In this test, we reconstruct a scenario
for a 3rd party to sweep an anchor spend after force closing, causing a
prior spend we had to be invalidated. Without the prior commit, this test
fails as the original anchor sweep is still found in the wallet.
It turns out that when a REST call to an endpoint (in this specific
example /v1/payments, which for GET returns all payments but for DELETE
removes all payments) is made with POST instead of the correct
registered method, the grpc-gateway tried to find a fallback method.
That resulted in randomly choosing between any of the calls with the
same URI pattern.
This is of course catasrophic if the user attempts to query the list of
payments (but using POST instead of GET by accident) and then ending up
calling the DELETE endpoint instead.
To help debug remote signing issues, it's helpful to get the raw PSBT
that failed to be parsed. This is necessary since serializing an invalid
PSBT is allowed and the checks only fail when trying to de-serialize
such an invalid packet.
We need to be able to query the watch-only wallet about a public key
when trying to sign with a key that we don't know the family or index
of. The easiest way to do that is to leverage the wallet's address index
to query the derivation path for a public key.
To give the RPC wallet access to that functionality, we need to expose
the method on the WalletController interface.
As a preparation for parsing addresses, we need the full network
parameters and not just the coin type in the RPC wallet.
Fixes an issue with SignOutputRaw in remote signing mode where we
weren't able to sign on the remote signer if we only provided the public
key or only the family/index (and not both).

Fixes part of an issue detected in lightninglabs/loop#457.
guggero and others added 4 commits March 24, 2022 16:26
Fixes lightningnetwork#6329.
This commit fixes a connection leak in the RPC wallet's health check. By
not closing the test connection the watch-only node would slowly stack
up connections and eventually hit the ulimit.
@Roasbeef Roasbeef changed the base branch from v0-14-2-branch to v0-14-3-branch-rc1 March 24, 2022 23:31
@Roasbeef
Copy link
Member Author

The branch builds for be locally, but I think maybe github is using a dated base branch? May need to remake it, or go through to ensure the cherry-picked commits apply more cleanly.

@Roasbeef Roasbeef closed this Mar 25, 2022
@Roasbeef Roasbeef reopened this Mar 25, 2022
@guggero
Copy link
Collaborator

guggero commented Mar 25, 2022

I think the problem is lnwire/signature.go:32 where we use the ecdsa package. We might need to hard code that value.

The "CI / check commits" and "CI / check submodules" likely won't be green as they try to rebase against current master.
But the other elements should become a bit greener.

@guggero
Copy link
Collaborator

guggero commented Mar 25, 2022

There are a few other imports missing, it seems.
Here's the diff that fixes compilation and all linter issues:
0.14.3-beta.rc1.diff.txt

Also, I went ahead and collected all entries from all PRs and updated the release notes.

I confirmed locally that the unit and integration tests work after running with the patch.

@Roasbeef
Copy link
Member Author

Roasbeef commented Mar 28, 2022

Thanks for those fixes! Gonna move forward with this, as all the main tests pass, other than some of commit/tag level tests due to the way the branch was constructed.

@Roasbeef Roasbeef merged commit 325daf1 into lightningnetwork:v0-14-3-branch-rc1 Mar 28, 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