rust-lightning

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

Require Route::route_params

This field has always been set since 0.0.117. Since we're making it required
here, routes created/serialized prior to 0.0.117 will fail to deserialize on
0.4.

Reject case-varied LSPS5 replay signatures

LSPS5 webhook signatures are zbase32 strings, and the verifier
accepts case aliases when decoding them. The replay cache compared
raw header strings, so a case-only change could bypass immediate
replay detection even though it represented the same signature bytes.

Canonicalize the verified signature text before cache lookup and
storage. Keying the replay cache on decoded signature bytes would be
the semantic ideal, but doing that locally would decode once in the
validator and again inside message_signing::verify. This keeps the
fix local while matching the verifier's identity semantics. Add
regression coverage for the case-varied replay.

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.

Encrypt `payment_metadata` when we build the payment secret

In 657ac8f58e51af74c610375cb65cdad6f7a18c6b we started committing
to the `payment_metadata` in the `payment_secret`. We'd largely
assumed that downstream code could simply encrypt the
`payment_metadata` itself before passing it to `lightning` and
decrypt before reading it from `lightning`. However, this presents
a challenge - we'd very much love for that downstream code to avoid
adding any extra bytes to its `payment_metadata` if at all
possible, but it doesn't have a great way to get a decent IV
without simply shoving it in the encrypted `payment_metadata`.

Instead, here, we encrypt and decrypt the `payment_metadata`
internally in `lightning`. This allows us to reuse the IV that is
used for `lightning`-generated `payment_hash`es as the IV for the
encrypted `payment_metadata` as well. Sadly, we don't have any
similar IV for user-provided `payment_hash`es. In that case, we
simply accept the limitations and document that users must avoid
encrypting multiple `payment_metadata`s for payments with the same
`payment_hash`. This avoids padding the size of the
`payment_metadata` and should generally not be a material concern -
`payment_hash` reuse should generally not exist anyway, and if it
does it should only be in cases where its "the same payment" being
retried after failure, at which point `payment_metadata` should
hopefully be the same.

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.

Gate interactive commitment_signed on user approval during reestablish

Interactive funding transactions must be approved by the user via
`ChannelManager::funding_transaction_signed` prior to exchanging
signatures for it. This ensures the user is able to cancel up until the
very last point throughout the handshake. When this was done in 83b2d3e,
we forgot the cover the reestablish cases, which we do here.

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.

Document script_pubkey-only matching in into_unique_contributions

The function compares outputs by script_pubkey alone, not full TxOut,
so any contribution output sharing a script with an existing output is
filtered regardless of value. This is intentional — a change output's
value may shift between rounds (e.g., for a new feerate) and should
still match. But the consequence isn't obvious: multiple contribution
outputs sharing a script are all filtered together when any existing
output uses that script. Document it.

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

Run `cargo fmt` on `maybe_downgrade_channel_features`

Support async signing of splice shared input

While user signatures may be provided whenever ready at the user's
discretion when handling a `FundingTransactionReadyForSigning` event, it
does not cover the user's signature for the 2-of-2 multisig input in a
splice. This signature is obtained via the `EcdsaChannelSigner`, which
did not support providing it asynchronously.

Since the splice shared input signature is part of the `tx_signatures`
message, we're not allowed to send the message until it's complete. This
results in us needing to explicitly handle the signature exchange logic
when the signer unblocks the shared input signature.

Error if the calculated v1 reserve is greater than the channel value

We made the same change to the calculation of the v2 reserve in the
previous commit.

Rename should_reset_pending_splice_state argument

There's a case in `should_reset_pending_splice_state` where we are
awaiting signatures, but still want to preserve the pending negotiation
upon a disconnection. We previously used `counterparty_aborted` as a way
to toggle this behavior. Now that we support the user manually canceling
an ongoing negotiation, we interpret the argument a bit more
generically in terms of whether we wish to resume the negotiation or not
when we are found in such a state.

Strip Unicode `Cf` characters in `PrintableString`

`PrintableString` is the sanitiser LDK uses to render untrusted strings
(node aliases, BOLT-12 invoice / offer text, `UntrustedString`, LSPS
messages, `lightning-invoice` descriptions) to logs and UI. It only
replaced `char::is_control` matches (Unicode general category `Cc`)
with U+FFFD, leaving the entire `Cf` (Format) category untouched.

That is the exact category covering the bidirectional override /
isolate codepoints (U+202A..U+202E, U+2066..U+2069) and zero-width
characters (U+200B..U+200D, U+FEFF) behind the "Trojan Source" attack
family (CVE-2021-42574): a peer can set its alias / invoice description
/ offer fields to e.g. `safe\u{202E}cipsxe.exe`, which previously
passed through verbatim while a human reader sees `safeexe.cips` —
defeating the threat model `PrintableString` exists to defend against.

Replace `Cf` codepoints alongside `Cc` ones. The `Cf` ranges are
inlined as a `matches!` table sourced from Unicode 16.0 to keep the
change `no_std`-friendly with no new dependencies.

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

Simplify contribution pop in reset_pending_splice_state

The was_negotiated check is unnecessary because reset_pending_splice_state
only runs when funding_negotiation is present, meaning
on_tx_signatures_exchange hasn't been called yet. Since the feerate is
only recorded in last_funding_feerate_sat_per_1000_weight during
on_tx_signatures_exchange, the current round's feerate can never match
it. So the contribution can always be unconditionally popped.

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