Was discovered in a race unit test in lightning node connect that uses
the websocket proxy to connect to the hashmail server on the client
side.
By not shadowing the err variable we end up reading and writing to the
same variable from two different goroutines, which causes the data race.
If new default scopes are added to the underlying btcwallet
implementation, then they aren't automatically created for _existing_
wallets, only for new ones. So on startup we need to make sure all
scopes are present.
Because Taproot key spend only spends don't allow us to re-construct the
spent pkScript from the witness alone, we cannot support registering
spend notifications for v1 pkScripts only. We instead require the
outpoint to be specified. This commit makes it possible to only match by
outpoint and also adds an itest for it.
Fixes#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.
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.
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.
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.
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.
