It looks like in some cases (apparently mostly on Windows) a previous
sub test sometimes leaves some unconfirmed balance in the wallet. That
balance is confirmed in the next test when new coins are sent to the
wallet.
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.
Clarification that KeyDescriptor describes the public key in
raw_key_bytes and the key_loc identifies the private key. Helps
clarify responses from calls like DeriveKey and DeriveNextKey from
WalletKit.
Fixes#5899
[skip-ci]
payments-expiration-grace-period needs time unit h/m/s or else the lnd does not start.
; payments-expiration-grace-period=30s
Corrected minor typo.
Previously the assumption existed that panic data was already an error.
If that wasn't the case for example because panic("string") was used,
the transaction wasn't unlocked.
This commit ensures htlcs currently held by the interceptor
Are not sent again. This prevents potential races in the user code that
may lead to loosing funds.
In this commit, we add the setID to the invoiceEvent struct as it will
be useful when we need to be able to distinguish a new open invoice,
from an AMP invoice that's being settled for the first time.
we then update the logic during notification dispatch to utilize the new
field to allow it to detect the repeated settles of AMP invoices.
In this commit, we update the logic in `updateInvoice` to allow callers
to pass in either a hint, or the setID in the update callback. This
makes things more efficient for AMP invoices with thousands of recurring
payments, as we no longer need to read out _all_ the invoices each time
we go to update the state of a few HTLCs.
This change allows us to deliver notifications to a user of all the
settled recurring payments to the same payment_addr in the order that
they occurred.
In this commit, we modify the way we handle state updates for AMP
invoices. With the current logic, once an invoice is settled, we'll
update the primary invoice state. This means that a user can't take the
same payment_addr, w/ a new set_id and pay the invoice again.
To remedy this, we'll move to instead _not_ updating the main invoice
state each time a new htlc Set (group of HTLCs according to setID) is
added. Instead, given that each HTLC stores an individual state, we'll
instead just use that directly from now on.
We also update TestSetIDIndex to account for new repeated settle AMP
logic.
In this commit, we modify the HTLC storage for AMP invoice only to be
stored within a new key prefix next to the main invoice data. We do this
as otherwise each time an AMP invoice is settled (enabled by the
following commits), we need to continually encode+decode the _entire_
set of invoices.
Instead, we store the AMP invoices within the main invoice bucket, using
the invoice number as a key prefix, with the final key being:
`invoiceNum || setID`
In this commit, we add a new type `AMPInvoiceState` that's used to store
AMP sub-invoice meta data alongside the main invoice. This will be used
to allow changes to be made to an AMP invoices without reading out all
the HTLCs. In addition, callers can use this metadata to look up
information about the current sub-invoice state of AMP HTLCs.
In this commit, we add a new `LookupInvoiceV2` method attached to the
invoice RPC sub-server. Compared to the existing version, this version
allows an invoice to be looked up by an invoice ref. This enables users
to query an AMP invoice based on a specific _set ID_, so they can get
the information related to the set of cumulative settles to that
invoices.
In the case where lnd's config struct is embedded inside another struct
(for example in lightning-terminal), the flag won't be found under its
original name. So we try to also look it up under the prefixed name.
