-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
build: create v0.14.3 rc1 release branch #6366
Conversation
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.
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.
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. |
I think the problem is The "CI / check commits" and "CI / check submodules" likely won't be green as they try to rebase against current master. |
There are a few other imports missing, it seems. 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. |
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. |
PRs included in this branch:
May need some fixup commits to resolve some minor rebase issues, and also to re-create the release notes set for 0.14.3 (really just copy things over).