rust-lightning

Update crate repository links to forgejo

Retransmit splice_locked for 0-conf channels missing tx_signatures

When a 0-conf channel successfully negotiates a 0-conf splice only for
one peer and a disconnection happens prior to the other peer receiving
`tx_signatures`, we'd previously fail to handle the inferred
`splice_locked` upon reconnection via the
`my_current_funding_locked_txid` TLV since the peer had not considered
the splice fully negotiated yet. In this case, an explicit
retransmission of `splice_locked` is required as per the BOLT-2
requirement:

> Each node:
> - If option_zeroconf has been negotiated:
> - SHOULD send splice_locked immediately after exchanging tx_signatures.

Include to_self_delay size in DelayedPaymentOutput weight calculation

SpendableOutputDescriptor::create_spendable_outputs_psbt estimated the
witness weight of a to_local (DelayedPaymentOutput) input using
MAX_WITNESS_LENGTH, which assumes the maximum 4-byte OP_CSV push of
to_self_delay in the redeemscript. The real push can be as small as 1
byte for small to_self_delays, causing the estimate to overshoot by up
to 3 WU. If this overshoot occurred in addition to a short signature,
the max-overshoot debug_assert in KeysManager::spend_spendable_outputs
would fail.

Add DelayedPaymentOutput::max_witness_length, which computes the witness
length from the descriptor's actual to_self_delay, and use it in place
of the MAX_WITNESS_LENGTH constant. This produces a more accurate
weight estimate so that the debug_assert in spend_spendable_outputs
never fails.

This bug was discovered using Smite.

Require manual reviewer assignment

Stop assigning reviewers when pull requests are opened. Keep the manual
workflow trigger available for Forgejo's "Assign random reviewer"
button. Only members of the reviewer pool may request an additional
reviewer.

Document that contributors should address the initial AI review before
requesting human review. Clarify that one human reviewer is the default,
with a second requested when the primary reviewer considers it
necessary.

Handle missing splice tx_signatures on reestablish

When reconnecting after one side has received `tx_signatures` for a
splice but the peer has not, `channel_reestablish` may need to recover
two different pieces of state: the missing `tx_signatures` and a later
commitment update generated after quiescence ended locally.

Previously the lost-remote-commitment path discarded any `tx_signatures`
prepared while processing the peer's `next_funding` TLV, as we assumed
that if a `tx_signatures` is owed, then no pending updates must exist.
That left the peer awaiting splice signatures and still treating the
channel as quiescent, so the subsequent HTLC commitment update was
rejected as a normal update while quiescent.

This was incorrect as the fuzzer highlighted that a new update can be
made after the `tx_signatures` exchange (while the counterparty has yet
to process the responding `tx_signatures`) and both messages need to be
retransmistted after a reconnect.

We fix this by carrying `tx_signatures` through that reestablish branch
and making the `tx_signatures/commitment_update` order explicit. Initial
splice funding retransmission remains
commitment_signed-before-tx_signatures, while post-splice reconnect
recovery sends tx_signatures before normal commitment updates so the
peer can exit quiescence first.

offers: Allow disabling invoice response MPP

Preserve the MPP-enabled default for invoice-request response builders
so existing OffersMessageFlow callers retain their prior behavior.

Allow callers with single-path requirements to explicitly remove the
advertised MPP feature before signing. This controls feature
advertisement only; receive-side enforcement remains the caller's
responsibility.

Co-Authored-By: HAL 9000

Pin jobserver to 0.1.34 on pre-1.85 rustc

Test cross-version serialization of pending splices

Add tests exercising the 0.2/current wire boundary for pending splices:
- A current node with a single pending splice (whether or not we
contributed to it) is loadable by LDK 0.2.
- A current node with a splice under RBF is refused by 0.2 via the even
RBF-gate TLV.
- A single pending splice written by 0.2 is read by current with no
contribution recorded, since 0.2 never tracked one.

The downgrade reload configs enable anchors so 0.2 accepts the current
channel type rather than refusing it before the splice state is reached.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Require `htlc_value_satoshis` in [pending] `HTLCUpdate`s

In 0.0.100 we started tracking the amounts being claimed in
`OnchainEvent::HTLCUpdate` and then also in
`MonitorEvent::HTLCUpdate`'s `HTLCUpdate`. It was always set, but
stored as an `Option` to support further downgrade. Because these
objects time out after `ANTI_REORG_DELAY` (6) blocks, there's not
really much reason to keep supporting backwards compatibility to
upgrade with such objects without an amount.

In 0.0.115, we started providing the amount in `PaymentForwarded`.
For whatever reason, despite the event only being generated in
cases where we had amounts, the field was added as an `Option`.

Still, in 0.0.118 we started generating them from both off-chain
and on-chain claims. For off-chain claims it was always set, but
for claims which originated from on-chain claims, the amounts came
from the `MonitorEvent::HTLCUpdate` and thus were always an
`Option`. If we no longer care about `MonitorEvent::HTLCUpdate`'s
without a claim amount, we no longer need to worry about
`Event::PaymentForwarded` either. Thus, we make it required here
as well.

Use a builder for sign_interactive_funding_tx arguments

The signing helper had accumulated several boolean/option parameters beyond
the two nodes, so call sites passed opaque positional `false`s and bare
`None`s whose meaning was unclear without consulting the signature.

Replace the two overloaded functions with a single `sign_interactive_funding_tx`
taking a `SignInteractiveFundingTxArgs` builder, mirroring `PassAlongPathArgs`:
`new(initiator, acceptor)` defaults to a first-attempt splice on a confirmed
channel with no acceptor contribution, and each non-default behavior is opted
into by a named method (`zero_conf`, `with_acceptor_contribution`, `replacing`).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

ln: persist the paid BOLT 12 invoice and build payer proofs

Carry the paid `Bolt12Invoice` through the outbound payment so it survives
restarts, and surface it as a `PaidBolt12Invoice` on `Event::PaymentSent` so the
payer can build a payer proof. The payer signing key is re-derived from the
invoice's own payer metadata, so no extra key material is stored.

`PaidBolt12Invoice` now lives in `offers::payer_proof`; existing async payment
tests and a test helper are updated to construct it via the new API. Adds an
end-to-end test that pays a BOLT 12 offer and builds + verifies a payer proof
from the resulting `Event::PaymentSent`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

refactor(offers): extract payer key derivation helpers

Move the invoice/refund payer key derivation logic into reusable helpers so
payer proofs can derive the same signing keys without duplicating the metadata
and signer flow.

Upload new fuzz corpus entries as a short-lived CI artifact

Fork-PR runs get no credentials from Forgejo — neither secrets nor
authorized-integration identity tokens — so the fuzz job cannot push
new corpus entries to the corpus repo from CI. Instead, clone the
corpus from this Forgejo instance (rather than the GitHub copy, so
new entries are detected against the repo they will land in), stage
the new entries plus any SIG* crashes like the GitHub workflow does,
and upload them as an `hfuzz-corpus` artifact with a two-day
retention. The ldk-fuzzing-corpus repo's nightly job sweeps these
artifacts into a corpus pull request and deletes them once processed.

Unlike the GitHub workflow's version, the crash-staging loop here uses
the `rust-lightning/<target>` prefix the corpus entries are actually
staged under (upstream checks the wrong path, so no crash file is ever
picked up there), and it stages crashes for targets that produced no
new corpus entries rather than only creating the target directory as a
side effect of staging corpus files.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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).

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.

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

fuzz: add chanmon holder signer fuzz ops

Allow chanmon consistency fuzz inputs to block holder-side signer
operations and retry monitor-driven claim signing. The new commands
extend the existing signer-op blocking machinery to the holder
commitment and holder HTLC transaction paths.

Pin actions/checkout + actions/cache to a full URL and commit hash

Reference the checkout action by its explicit data.forgejo.org URL
pinned to a commit hash (v6) rather than the bare `actions/checkout@v4`
short form.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Lower strictness of pending monitor update while awaiting tx_signatures

We previously assumed that no monitor update should ever be pending when
receiving `tx_signatures` while quiescent, with the exception of the
`RenegotiatedFunding` variant. This was a bit too strict, as we did not
consider that if an HTLC was sent via the same channel, its preimage
could be received from upstream leading to a monitor update to durably
persist it.

This commit ensures that if the recipient of a `tx_signatures` has not
yet echoed theirs back, and it is awaiting a monitor update completion,
then the pending monitor update must be of the `RenegotiatedFunding`
variant. If the pending monitor update is of another variant, then we
must remain quiescent with no pending updates available to send until
after the `tx_signatures` exchange.

Ignore stale splice initial commitment_signed

After we complete a splice negotiation and see a
`FundingTransactionReadyForSigning` event, the counterparty may already
have sent its initial `commitment_signed` for the splice funding
transaction. If we then cancel the funding contribution, our local
channel state no longer tracks the pending splice attempt and queues
`tx_abort`, but the in-flight `commitment_signed` can still arrive
first. Handling that message against the post-abort channel state
attempts to validate a signature for the now-stale splice funding
transaction and can force-close the still-live channel.

We fix this by checking the optional `funding_txid` (which we expect all
implementations to always include by default) included in
`commitment_signed` before validating the commitment signature. If it
does not match the channel's locked funding txid, we can safely ignore
the stale message.

Pin zeroize for old Rust CI

zeroize 1.9.0 uses Rust 2024 metadata, which Cargo 1.75 cannot
parse. Pin it to 1.8.2 for older toolchains so the transaction sync
HTTPS feature check keeps passing on the MSRV job.

Format possiblyrandom cfg attributes

Run rustfmt on the possiblyrandom crate so its cfg attributes match
the current formatting rules.

Get real rand in `possiblyrandom` on supported platforms w/o feat

It turns out that conditionally-enabling a dependency via `target`
in `Cargo.toml` does not enable the corresponding dependency
`feature` when compiling the code. As a result, only when building
`possiblyrandom` with an explicit `getrandom` feature did we ever
actually return random values.

This fixes this by matching the `target` cfg in `Cargo.toml` to the
cfg in `lib.rs`.

Reported by Project Loupe

Reject pre-epoch `LSPSDateTime` at parse time

`LSPSDateTime::is_past` coerced `chrono`'s `i64` timestamp into a
`u64` via `try_into().expect(...)`. Because `LSPSDateTime` is parsed
from peer-controlled RFC 3339 strings (which can be pre-1970 and so
yield negative timestamps), this could be triggered remotely: an
attacker-supplied `valid_until` / `expires_at` field of e.g.
`"1900-01-01T00:00:00Z"` would parse successfully, land in LSPS state
before any HMAC / promise check, and panic the LSP thread on the next
`prune_pending_requests` sweep. Concretely reachable today via LSPS2
`opening_fee_params.valid_until` (in the buy request) and the LSPS1
expiry fields.

Make `LSPSDateTime::from_str` reject pre-epoch datetimes, and route
serde deserialization through it: `#[serde(transparent)]` was
delegating Deserialize directly to `chrono`'s impl and bypassing our
parser, so peer JSON had to be guarded separately. With both paths
funnelled through one parser, no `LSPSDateTime` value with a negative
inner timestamp can be constructed and `is_past` is safe by
construction.

Co-Authored-By: HAL 9000

Use BOLT11 invoice payee keys for payment params

Payment parameters should use the canonical payee key from BOLT11
invoices. When an invoice includes an n field, using that key avoids
attempting signature recovery that may legitimately be unavailable.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe