Fixes#6396.
This commit fixes a panic that occurred when trying to sign for a
Taproot output without specifying the full UTXO information for each
input. Instead of panicking an error is now returned.
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 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.
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.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
Update our test to assert that we have hop hints present when we
expect them, and fix the "alice is a private node" issue that was
previously preventing us from adding hop hints. Asserting that we
have hop hints present in this itest ensures that we'll fail our
itests if a change to SelectHopHints results in our no longer
having hints in this secnario.
This sets the `CustomCaveatCondition` value on rpc middleware requests
if one exists. Previously, this value was always blank even if the
macaroon had a value set for its custom caveat condition.
This fixeslightninglabs/loop#437 by adding all accounts that are used
in liquidity products such as Loop or Pool. Since both of these products
use key families below 255, we can get by with that number.
The alternative to creating way too many accounts (which increases the
default wallet size by ~250kB) would be to hard code the exact accounts
used by Loop (99) and Pool (210). But that sounds like a bad idea given
that there could always be more accounts being added to those (or other)
products. By making sure the first 255 accounts exist, we have a lot
more flexibility in those products for choosing key families.
With the remote signing instance now not needing to know anything about
addresses or current derivation indices, we don't need to forward any
such calls to that instance and can simplify the RPCKeyRing
considerably.
This adds an integration test that makes sure channel can be funded from
empty wallet using PSBT if the funding transaction contains an output
belonging to the wallet, satisfying the reserve.
This commit removes the context as a param needed when calling methods
of HarnessNode. This change moves the context management inside
HarnessNode, aside from saving us a few lines, it makes the context
creation/timeout less error-prone.
This commit adds a unique request ID that is the same for each gRPC
request and response intercept message or each request/response message
of a gRPC stream.
This commit adds a new unique intercept message ID that is different for
each message sent to an RPC middleware. This will allow us to re-purpose
the existing request ID field into its original intention, which was to
have a unique ID for a full gRPC request/response pair or gRPC stream as
a whole.
It looks like in some cases a channel is still being closed while we
already try to create a sweep output. In that case the pending closed
channel is still counted as anchor channel and a reserve output is
created. To make sure that doesn't happen, we make sure there are no
pending or open channels of any kind around before we create the sweep
transaction.
