rust-lightning

ln/test: add tests for mpp accumulation of trampoline forwards

ln/test: add test coverage for MPP trampoline

ln/tests: return BlindedPaymentPath from trampoline helper

Now that PaymentParameters are required, surface path along with blinded
tail for use in tests.

ln: process added trampoline htlcs with CLTV validation in tests

We can't perform proper validation because we don't know the outgoing
channel id until we forward the HTLC, so we just perform a basic CLTV
check.

We don't yet have proper handling of trampoline forwards on restart, so
we only enable this in our tests.

ln: handle DecodedOnionFailure for local trampoline failures

While proper error handling will be added in a followup, we add the
bare minimum required here for testing.

Note that we intentionally keep the behavior of not setting
`payment_failed_permanently` for local failures because we can possibly
retry it because we're the sender as a trampoline forwarder.

For example, a local ChannelClosed error is considered to be permanent,
but we can still retry along another channel.

ln: double encrypt errors received from downstream failures

If we're a trampoline node and received an error from downstream that
we can't fully decrypt, we want to double-wrap it for the original
sender. Previously not implemented because we'd only focused on
receives, where there's no possibility of a downstream error.

While proper error handling will be added in a followup, we add the
bare minimum required here for testing.

ln: add trampoline mpp accumulation with rejection on completion

Add our MPP accumulation logic for trampoline payments, but reject
them when they fully arrive. This allows us to test parts of our
trampoline flow without fully implementing outbound dispatch.

This commit keeps the same first_claimable_htlc debug_assert behavior
as MPP claims, asserting that we do not fail our
check_claimable_incoming_htlc merge for the first HTLC that we add to a
set. This assert can only be hit if our first part exceeds the
`MAX_VALUE_MSAT`, which should not be hit because we check individual
amounts elsewhere in the codebase (the check exists to check that
multiple parts combined don't hit this overflow).

Make SpliceFundingFailed::contribution non-optional

`SpliceFundingFailed` is only constructed from a concrete
`FundingContribution`, so store it directly.
`Event::SpliceNegotiationFailed::contribution` still needs to be
optional as it could be read from a prior version that did not store
contribution data.

Check channel is live while handling counterparty tx_init_rbf

This mirrors what we do for counterparty `splice_init` messages, making
sure we don't accept RBFs once a channel has requested shutdown.

Prefer tx_abort over disconnection for splice negotiation errors

We keep some `WarnAndDisconnect` cases as mandated by the spec, but
otherwise prefer sending `tx_abort` to terminate quiescence and avoid
reconnection loops.

Prefer tx_abort over disconnection for inability to RBF

Send `tx_abort` to terminate quiescence and avoid reconnection loops.

Allow invalid contribution error upon quiescence

While a contribution may be valid at the time the splice is requested,
quiescence still needs to happen, which can affect the balances of the
channel as it fully settles all pending state. After doing so, it's
possible that the contribution is no longer valid. Since quiescence
itself doesn't have a terminal message, we see a `WarnAndDisconnect`
event happen.

Always emit SpliceNegotiationFailed when contributing

Previously, this could result in an acceptor not receiving a
`Event::SpliceNegotiationFailed` for a splice in which they reused the
same contribution (except for the feerate change). Our API should
guarantee that users should always see `SpliceNegotiated` and
`SpliceNegotiationFailed` events for splices that they contribute to.

Only emit Event::SpliceNegotiated when contributing

There's no need to inform users of negotiated splices when they're not
contributing as it just produces noise. Once they do start contributing,
they cannot stop, so we always emit the event going forward. Note that
we still emit `Event::ChannelReady` with the new locked funding outpoint
for each locked splice, so users can still learn that a splice occurred
that way.

ln: add awaiting_trampoline_forwards to accumulate inbound MPP

When we are a trampoline router, we need to accumulate incoming HTLCs
(if MPP is used) before forwarding the trampoline-routed outgoing
HTLC(s). This commit adds a new map in channel manager, and mimics the
handling done for claimable_payments.

We will rely on our pending_outbound_payments (which will contain a
payment for trampoline forwards) for completing MPP claims,
not want to surface `PaymentClaimable` events for trampoline,
so do not need to have pending_claiming_payments like we have for MPP
receives.

This map is not persisted, as we're currently working on refactoring
restart logic to depend on channel monitors. We should not use this
accumulation map in production yet, as we can hit a force close if:
- We are used as a trampoline, despite not supporting the feature
- A trampoline MPP part arrives and is committed to the inbound channel
and added to `awaiting_trampoline_forwards`
- We restart and the MPP part is not re-added to
`awaiting_trampoline_forwards`

In this scenario, we will not hit our MPP timeout logic for this HTLC
because we have "forgotten" about it. It will be up to our counterparty
to force close the channel on us, because we're not failing it back
after we hit MPP timeout. Likewise, even if other MPP parts arrive,
we won't consider the inbound accumulation to be complete so we'll fail
them back but forget about the HTLC that came before the restart.

We currently reject trampoline HTLCs earlier in the lifecycle, so we
are not at risk of producing a state that could trigger such a force
close. In the commits that follow, we'll allow forwarding of
trampoline HTLC for tests so that we can start to cover this code.

ln: use outer onion values for trampoline NextPacketDetails

When we receive trampoline payments, we first want to validate the
values in our outer onion to ensure that we've been given the amount/
expiry that the sender was intending us to receive to make sure that
forwarding nodes haven't sent us less than they should.

ln: store next trampoline amount and cltv in PendingHTLCRouting

When we're forwarding a trampoline payment, we need to remember the
amount and CLTV that the next trampoline is expecting.

ln: use outer onion values in PendingHTLCInfo for trampoline

When we are a trampoline node receiving an incoming HTLC, we need access
to our outer onion's amount_to_forward to check that we have been
forwarded the correct amount. We can't use the amount in the inner
onion, because that contains our fee budget - somebody could forward us
less than we were intended to receive, and provided it is within the
trampoline fee budget we wouldn't know.

In this commit we set our outer onion values in PendingHTLCInfo to
perform this validation properly. In the commit that follows, we'll
start tracking our expected trampoline values in trampoline-specific
routing info.

ln: store incoming mpp data in PendingHTLCRouting

When we receive a trampoline forward, we need to wait for MPP parts to
arrive at our node before we can forward the outgoing payment onwards.
This commit threads this information through to our pending htlc struct
which we'll use to validate the parts we receive.

ln: use total_msat to calculate the amount for our next trampoline

For regular blinded forwards, it's okay to use the amount in our
update_add_htlc to calculate the amount that we need to foward onwards
because we're only expecting on HTLC in and one HTLC out.

For blinded trampoline forwards, it's possible that we have multiple
incoming HTLCs that need to accumulate at our node that make our total
incoming amount from which we'll calculate the amount that we need to
forward onwards to the next trampoline. This commit updates our next
trampoline amount calculation to use the total intended incoming amount
for the payment so we can correctly calculate our next trampoline's
amount.

`decode_incoming_update_add_htlc_onion` is left unchanged because
the call to `check_blinded` will be removed in upcoming commits.

ln: remove incoming trampoline secret from HTLCSource

We don't need to track a single trampoline secret in our HTLCSource
because this is already tracked in each of our previous hops contained
in the source. This field was unnecessarily added under the belief that
each inner trampoline onion we receive for inbound MPP trampoline would
have the same session key.

It can be removed with breaking changes to persistence because we
currently refuse to decode trampoline forwards, and will not read
HTLCSource::Trampoline to prevent downgrades.

ln/refactor: use amount_msat and counterparty_skimmed_fee_msat vars

Followup from prefactor PR.

Fix Joost's Forgejo username

Use the account name present on this Forgejo instance so Joost stays
in the reviewer rotation.

Co-Authored-By: HAL 9000

Use Forgejo OIDC for review requests

Request a local Authorized Integration JWT in the reviewer workflow.

Use bearer authorization for the reviewer request API call.

This avoids a long-lived user token.

The workflow still gets the missing reviewer-request capability.

Co-Authored-By: HAL 9000

Update upstream CHANGELOG with latest 0.1/0.2 releases