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.
Add a new subpackage to `lnd/channeldb` to hold some of the types that
are used in the package itself and in other packages that should not
depend on `channeldb`.
This commit moves the `HeightHintCache` implementation to the
`channeldb` package and inverts the dependency relation between
`chainntnfs` and `channeldb`.
Many packages depend on channeldb for type definitions,
interfaces, etc. `chainntnfs` is an example of that. `chainntnfs`
defines the `SpendHintCache` and `ConfirmHintCache` interfaces but
it also implments them (`HeightHintCache` struct). The implementation
uses logic that should not leak from channeldb (ex: bucket paths).
This makes our code highly coupled + it would not allow us to use any
of these interfaces in a package that is imported by `channeldb`
(circular dependency).
Our OpenChannelRPC was accepting invalid values for the closing address
field. If we were able to decode the address we would use it in the
script even if the address is for another bitcoin net.
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.
This commit fixes signing of Taproot inputs when some of the other
inputs of the transaction are not known to the wallet (such as a Pool
account for example).
If we want to sign for a Taproot (change) input when depositing into a
Pool account the wallet won't know the Pool account input. So we need to
make sure we pass it along inside the PrevOutputFetcher (which contains
the UTXO information extracted from the PSBT).
This commit fixes an issue with signing for mixed inputs in a remote
signing setup where the re-use of the sign descriptor would lead to the
sign method not being reset correctly if a p2wkh input is following a
p2tr input.
In this commit, we modify the way we compute the starting ideal fee for
the co-op close transaction. Before thsi commit, channel.CalcFee was
used, which'll compute the fee based on the commitment transaction
itself, rathern than the co-op close transaction. As the co-op close
transaction is potentailly bigger (two P2TR outputs) than the commitment
transaction, this can cause us to under estimate the fee, which can
result in the fee rate being too low to propagate.
To remedy this, we now compute a fee estimate from scratch, based on the
delivery fees of the two parties.
We also add a bug fix in the chancloser unit tests that wasn't caught
due to loop variable shadowing.
The wallet import itest has been updated as well, since we'll now pay
600 extra saothis to close the channel, since we're accounting for the
added weight of the P2TR outputs.
Fixes#6953
In this commit, the sanity checks in the CommitConstraints method is
moved out into a helper function called VerifyConstraints. This is done
so that the sanity checks can be performed more easily else where in the
code base. The new helper method is then called in the
handleInitFundingMsg method of the funding manager before the
OpenChannelMessage is sent.
In this commit, we catch up our logic with the latest version of the
spec that removed support for normal p2kh and p2sh addresses for co-op
closes, in order to make dust calculations more uniform.
In this commit, we remove the raw channel state machine pointer from the
chan closer and instead replace that with an interface that captures
*just* the methods we need in order to do the co-op close dance.
This is a preparatory refactoring for some upcoming unit tests.
In this commit, we stop clamping the ideal fee rate to the commitment
fee of the channel. This catches us up to this PR of the spec:
https://github.com/lightning/bolts/pull/847.
We also do away with the old 3x ideal fee "max fee", and replace that
with an explicit max fee. This new max fee will either be the default
multiplier of the ideal fee, or a new user specified max fee value.
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.
This extends the Reservation arguments to include whether a pending
channel open has negotiated the zero-conf channel type, the scid-alias
channel type, and/or the scid-alias feature bit. The result of those
negotiates are stored in the OpenChannel's ChanType. The arguments to
NewChannelReservation have also been simplified.
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.
Because the original dcrec secp256k1 library that is used for the
Schnorr signature primitives uses different hash algorithms than the
btcd secp256k1 library. Therefore pulling in the wrong library can lead
to weird and unexpected errors. We try to make it harder to make the
mistake by not using the library directly in lnd in the first place.
Note that it is still indirectly needed by the btcd secp256k1 library,
therefore the module dependency is still expected to be there, just
moved to the indirect section.
