This commit adds a new build tag `integration` and removes the old tag
`rpctest` for clarity. Multiple unnecessary usages of `build !rpctest`
is also removed.
By default, P2TR addresses are used for changes. However, some users
might encounter some problems with this change. We add the possibility
to define a custom address type in FundPsbt for default/imported accounts
(only P2TR for now). If no address type is specified for these accounts,
we will use P2WKH by default.
With this commit we bump the github.com/btcd/btcec/v2 library to v2.3.2
which implements the MuSig2 BIP version v1.0.0rc2. With this the
github.com/btcsuite/btcd/btcec/v2/schnorr/musig2 package becomes
v1.0.0rc2 and the github.com/lightningnetwork/lnd/internal/musig2v040
stays at the old v0.4.0 version.
We put the calls that don't use musig2 package specific types as
parameters or return values behind an interface so we can easily call
those directly in the RPC without needing to know the underlying
implementation version. Some calls can't be used in the interface
because they use the specific package version's types. These calls are
implemented in helper functions in the input package instead that do the
necessary type switches.
As a preparation for making it possible to version switch calls to the
MuSig2 API, we move some of the calls to the input package where in a
future commit we'll call the corresponding code in the correct package.
Before this commitment, we'd end up failing in `schnorr.ParseSignature`
if a non-default sighash was used. To fix that, we'll slice the
signature to only pass in the sig w/o the sighash flag.
This commit makes sure that no loop variables or other temporary
variables are accessed directly in a goroutine but are instead passed
into the goroutine through a parameter. This makes sure a copy of the
value is put on the stack and is not changed while the outside loop
continues.
With a change in #6379 we made sure that all default scopes are added to
the the wallet. Unfortunately this included the BIP044 key scope that
our wallet doesn't really use. This breaks the remote signing setup
because we don't export the account of the BIP044 scope and therefore
run into an issue on the watch-only side when attempting to create the
wallet.
Fixes#6626.
If either of the two fields FinalScriptSig or FinalScriptWitness is set
on an input of a PSBT then that results in most of the fields of that
input not to be serialized in the packet anymore, since the input is
considered to be complete.
But because a signer isn't supposed to set any of the Final* fields,
this was wrong from the beginning. Only the finalizer will set those
fields.
In this commit, we add a new field `TapTweak` to be used for key path
spends. Before this commit, we'd overload the existing `WitnessScript`
field to pass this information to the signing context. This was
confusing as for tapscript spends, this was the leaf script, which
mirrors the other script based spending types.
With this new filed, users need to set this to the script root for
keypath spends where the output key commits to a real merkle root, and
nothing when bip 86 spending is being used.
To make the signing even more explicit, we also add a new field called
sign_method with an enum type that differentiates between the different
segwit v0 and v1 signing methods.
Fixes https://github.com/lightningnetwork/lnd/issues/6446.
The inclusion proof field in the TapscriptPartialReveal function was
incorrect. An inclusion proof can be zero or more elements of 32-byte
slices. So an empty inclusion proof can be valid too for a tree that
only consists of a single leaf.
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.
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.
With `OutputDetail` now containing the destination addresses, the `DestAddresses` field can be removed from the `lnwallet.TransactionDetail`. It is already populated when needed for backwards compatibility to `lnrpc.TransactionDetail` via `OutputDetail.Addresses`.
Adds the output script and amount to the `DestOutput` field of `TransactionDetails`, as well as sets the flag `isOurAddress` if the output is controlled by the node's wallet.
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#6241
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
To enable converting an existing wallet with private key material into a
watch-only wallet on first startup with remote signing enabled, we add a
new flag. Since the conversion is a destructive process, this shouldn't
happen automatically just because remote signing is enabled.
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.
