rust-lightning

Update crate repository links to forgejo

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.

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

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.

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.

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

Fix: reject fake scids with invalid vout

Previously, we would spuriously allow fake scids that had a vout with the high
byte set to pass our is_valid_{phantom,intercept,etc}_scid checks, even though
our fake vouts only ever set the lowest 3 bits of the 2-byte vout.

This can't really be exploited since HTLCs that pass this check would still
fail later on in the pipeline, and attackers that want to craft fake scids to
pass our checks can still do so after this fix, either via brute force or by
reusing a valid fake scid from a previously issued invoice. But at least this
makes it harder for them to do so, and makes the check more correct than it was
before. Plus invalid fake crafted scids like this could theoretically cause us
to generate a spurious HTLCIntercepted event, which wouldn't be ideal.

Reported by Project Loupe.

Remove nonce from outbound payment OffersContexts

Now that the payer nonce is included in the payer metadata of
InvoiceRequest and Refund, Bolt12Invoice verification no longer needs
the nonce from the blinded path's OffersContext. Remove it from
OffersContext::OutboundPaymentForOffer and
OffersContext::OutboundPaymentForRefund, along with
enqueue_invoice_request's nonce parameter, which only existed to supply
it. The nonce in RetryableInvoiceRequest is no longer used either but
is still persisted -- and retained when reading state written by prior
versions -- so that such versions can retry the payment and verify the
resulting invoice after a downgrade.

The payment_id is kept in both variants, however. While no longer needed
to confirm the invoice is for an invoice request or refund we created,
it is checked against the payment id recovered from a received
Bolt12Invoice's payer metadata to ensure the invoice arrived over the
blinded path created for that payment. This prevents an attacker from
reusing the blinded path of one of our payments to deliver another
payment's invoice and correlate the two as ours.

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

Include payer nonce in payer metadata again

InvoiceRequest and Refund have payer metadata consisting of an
encrypted payment id and, originally, a nonce used to derive the payer
signing keys and authenticate any corresponding invoices. The nonce was
elided to save space once it was included in the OffersContext of
blinded reply paths, but that means verifying a Bolt12Invoice requires
state outside the invoice itself. Upcoming payment proofs (#4297) need
the invoice signing keys derivable from the invoice request alone, so
include the nonce in the payer metadata again and verify invoices using
it rather than the context's nonce.

This breaks verification of invoices for invoice requests and refunds
with blinded paths created by prior versions, as their payer metadata
lacks the nonce; such payments will fail and must be retried with a new
payment id. Refunds without blinded paths are unaffected, as their
metadata always included the nonce.

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

Return P2WSH script pubkey for keyed anchor prevouts

AnchorDescriptor::previous_utxo is used for coin selection and PSBT witness_utxo metadata. For keyed anchors it should describe the on-chain P2WSH anchor output instead of the witness script so wallets can validate and sign the package.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe

Ignore stale splice signing fuzz events

Now that the fuzz target supports canceling splice funding attempts, we
may see failed signing attempts due to the cancellation.

Rename read-write TLV ser macros

Rename TLV macros that generate both Readable and Writeable
impls to use the impl_ser_tlv_based prefix. Keep the MaybeReadable
upgradable enum helpers and shared write-only enum helper under
writeable naming so macro names match the traits they generate.

Allow stdin fuzz targets to suppress logs

Add an environment-variable switch that lets stdin fuzz targets use the
dev-null test logger. This keeps direct invocations verbose by default,
while external runners can opt into quieter passing-case replays.

Fix fuzz build warnings

Restore splice fuzzing by default

This removes the temporary cfg flag that was added while the splice
fuzzer was broken. We also include coverage for the newly supported
async signing of a splice's shared input.

Unify and simplify the application of simple chacha20 passes

Most of our `chacha20` calls don't actually care about the concept
of ChaCha20's "seek" vs "nonce" - we just want to use the full
128 bits of nonce space as nonce. Here we unify those calls to
keep a consistent API and consolidate the `unwrap`s to one place.

Handle overflowing route-hint fee aggregates

Crafted route hints can overflow aggregate downstream proportional fees
when the payer disables the routing fee cap. Treat such paths as
unusable so route finding fails cleanly instead of panicking.

Co-Authored-By: HAL 9000
Signed-off-by: Elias Rohrer <dev@tnull.de>

Account for fuzz signature weight

When secp256k1_fuzz is active, dummy ECDSA signatures may
serialize one byte larger per signature. Use fuzz-aware witness
estimates for keyed-anchor bumping and HTLC resolution so debug
weight assertions and aggregation limits use the fuzz signer bound.

Avoid grind signatures in fuzz builds

Disable default lightning features in the fuzz crate and persister
so fuzz builds do not inherit grind_signatures.

Add a compile-time guard for fuzzing plus grind_signatures.
Refresh the splice fuzz seed because the no-low-R weight model
changes the signed funding transaction amount and fake-hash txid.