With this commit we make sure the first hop custom records aren't lost
on restart/resume of a payment, so we persist it as part of the
PaymentCreationInfo struct.
This commit extends the forward HTLC intercept response with fields that
can be used in conjunction with a `ResumeModified` action to modify the
intercepted HTLC p2p message.
Introduce `ResumeModified` action to resume standard behavior of a p2p
message with optional modifications as specified by the client during
interception.
- Introduce the field `CustomRecords` to the type `UpdateFulfillHtlc`.
- Encode and decode the new field into the `ExtraData` field of the
`update_fulfill_htlc` wire message.
- Empty `ExtraData` field is set to `nil`.
- Introduce the field `CustomRecords` to the type `UpdateAddHtlc`.
- Encode and decode the new field into the `ExtraData` field of
the `update_add_htlc` wire message.
Because we restrict custom SCID aliases to be in a specific range, we
export the range start and end values so a user of the RPCs we're going
to add in the next commits can adjust their values to fit within the
range.
With the new RPC calls that we are going to add in the next commits, it
will be possible for users to add (local only, non-gossipped) SCID
aliases for channels. Since those will be in the same range as the ones
given out by RequestAlias, we need to make sure that when we generate a
new one that it doesn't collide with an already existing one.
In this commit, we expand some of the existing chan sync tests to cover
taproot channels (the others already did). Along the way, we always
assert that the `PartialSig` is populated on retransmission. In
addition, we now send the new commit sig rather than the existing
in-memory one to test the new logic that re-signs the commitment.
In this commit, we fix an existing bug with the taproot channel type
that can cause force closes if a peer disconnects while attempting to
send the commitment signature.
Before this commit, since the `PartialSig` we send is never committed to
disk, the version read wouldn't contain the musig2 partial sig. We never
write these signatures to disk, as each time we make a new session, we
need to generate fresh nonces to avoid nonce-reuse.
Due to the above interaction, if we went to re-send a signature after a
disconnection, the `CommitSig` message we sent wouldn't actually contain
a `PartialSigWithNonce`, causing a protocol error.
Previously, the SQL implementation of the invoice query simply
converted the start and end timestamps to time and used them
in SQL queries to check for inclusivity. However, this logic
failed when the start and end timestamps were equal.
This commit addresses and corrects this issue.
Previously SQL invoice updater ignored the set ID hint when updating an
AMP invoice resulting in update subscriptions returning all of the AMP
state as well as all AMP HTLCs. This commit synchornizes behavior with
the KV implementation such that we now only return relevant AMP state
and HTLCs when updating an AMP invoice.
When fetching an AMP invoice we sometimes filter HTLCs to selected set
IDs, however we always kept the full AMP state which is irrelevant as it
contains state for all AMP payments. This was a side effect of
UpdateInvoice needing to serialize the whole invoice when storing after
an update but it is an unwanted "feature" as users will need to filter
to relevant set when listing an AMP payment or subsribing to an update.
This commit squashes the below operations for a net result where
we have an expanded capability of assessing pending updates. This
is made possible by packing the components into Duals in the prior
commits. We squash the operations to simplify review.
htlcswitch+lnwallet: rename PendingLocalUpdateCount
lnwallet: complete pending update queries API for LightningChannel
lnwallet+htlcswitch: consolidate NumPendingUpdates using ChannelParty
This commit makes the observation that we can cleanly define the
NumPendingUpdates function using a single expression by taking
advantage of the relevant fields being properly packed into Duals.
This is yet another commit that packs a symmetric structure into
a Dual. This is the last one needed for the time being to consolidate
Num{X}UpdatesPendingOn{Y} functions into a single one.
This commit, like the last one packs the update logs into a symmetric
Dual structure. This will allow us to index into them more concisely
in higher order logic.
This commit packs the LightningChannel's localCommitmentChain and
remoteCommitmentChain into a Dual structure for better symmetric
access. This will be leveraged by an upcoming commit where we want
to more concisely express how we compute the number of pending
updates.
In this commit, we start to thread thru the new aux tap leaf structures to all relevant areas. This includes: commitment outputs, resolution creation, breach handling, and also HTLC scripts.
