In this commit, we fix a detected flake: we go to make a payment, and
then want to assert that 2 attempts we required. The existing logic
assumes that the success and the payment will still be on disk. With a
recent PR, we now delete failed payments by default, but after the fact,
in a non-atomic fashion.
We fix this issue simply by having all the nodes keep around failed
payments for the sake of all the old itests that assumed this
information would always be on disk.
Introduced in: https://github.com/lightningnetwork/lnd/pull/6438.
Fixes https://github.com/lightningnetwork/lnd/issues/6711.
In this commit, we modify the `macaroons.NewService` consturctor to
accept the main interface rather than the raw DB. This allows us to use
other backends other than bolt or the kvdb interface to store the
macaroon root keys.
We also create a new ExtendedRootKeyStore interface that implements some
of the more advanced features we use such as macaroon encryption and
password rotation.
In this commit, we consolidate the _lease specific_ logic for the
success and timeout HTLC resolvers. We do this with the addition of a
new struct which is then composed via struct embedding with the two
existing structs. This fixes a flake in the integration tests by
ensuring the height is set up front, rather than eventually once the
height matches the lock time.
This commit upgrades to the latest version of btcwallet that fixes an
issue that would cause us to not properly sign a validate populated PSBT
in certain scenarios.
Fixes https://github.com/lightningnetwork/lnd/issues/6579
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.
In this commit, we update the min Go version to be version 1.18. This
breaks our prior rule of supporting the last two major versions, but
allows us to use the larger features in 1.18 sooner, such as the newly
released type parameters.
In this commit, we start to ignore the option to allow the caller to use
the legacy onion payload. The new payload is much more flexible and
efficient, so there's really no reason to still use it, other than for
backwards compatibility tests. Our existing tests that exercise the
legacy feature uses a build tag, which forces nodes to not advertise the
new payload format, which then forces path finding to include the legacy
payload, so we can be confident that route is still being tested.
The existence of this option (which actually makes the TLV payload
opt-in for `SendToRoute` users) makes it harder to remove it from the
protocol all together. With this PR, we take a step forward to allowing
such a change which is being tracked on the spec level at:
https://github.com/lightning/bolts/pull/962.
In a future release, we'll move to remove the field all together.
Ignoring the field today doesn't seem to have any clear downsides, as
most payments always include the MPP payload (due to payment secrets),
so this shouldn't impact users in a significant way.
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.
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
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.
In this commit we update go-pretty to use the latest v6 version of the
library. The existing version we used had a reported vulnerability.
Updating to this newest version also helped to shrink our set of
indirect dependencies.
In the future we can use
https://github.com/lightningnetwork/lnd/pull/5870 to detect/flag these
issues automatically.
Fixes#6293
In this commit, we increase the legacy fee limit threshold (the amount
below which we'll allow 100% of funds to go to fees for the non-v2 RPC
calls) from 50 sats to 1k sats.
In this commit, we expose a new monitoring option to allow users to
export gRPC performance metrics. These metrics can be used to see how
long certain calls are taking, the total amount of time spent handling
calls, broken down by service and also call.
This option consumes additional memory and disk space for the Prometheus
server, which is why we're opting to make it an optional flag.
Olaoluwa Osuntokun