rust-lightning

Merge PR 'Fix CI fuzz job' (#4862)

from 2026-08-fix-fuzz into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4862
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

Merge PR 'Prevent unsafe splice RBF contribution queueing' (#4823)

from prevent-splice-rbf-enqueue-as-fresh into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4823
Reviewed-by: jkczyz <jkczyz@noreply.git.rust-bitcoin.org>
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

Fix CI fuzz job

Previously failed with "error: cannot install package `honggfuzz 0.5.62`, it
requires rustc 1.85 or newer, while the currently active rustc version is
1.75.0."

Merge PR 'Error Wrapping and Route Building for Trampoline Forwards' (#4808)

from 2299-error-wrapping into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4808
Reviewed-by: Val Wallace <val@noreply.git.rust-bitcoin.org>

Merge PR 'Only fetch TXIDs instead of entire block during gossip verification' (#4846)

from gossip-verify-rpc into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4846
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

Merge PR 'Allow filtered block rescans at the current tip' (#4847)

from 2026-08-block-replay into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4847
Reviewed-by: jkczyz <jkczyz@noreply.git.rust-bitcoin.org>

Add test framework coverage of `Listen` block connection replays

While this should generally be equivalent to receiving a block
duplicatively via the `best_block_updated` +
`transactions_confirmed` methods, its good to add explicit test
coverage for the newly-supported (but always documented...)
connection mode.

Update functional test block connection to detect block replays

In cases where we replay a block, the functional test framework
shouldn't consider it a new block and re-add it to the tracked
blockchain in `Node`s.

Correct HTLC confusion on unrevoked counterparty commitment txs

When we see an HTLC on an unrevoked counterparty commitment
transaction we check if it has a corresponding `HTLCSource` when
deciding whether it is likely from a revoked counterparty
commitment transaction. This is insufficient, however, and can
result in us assuming that an HTLC is on a revoked counterparty
commitment (and thus is safe to fail back based on a loose HTLC
match) rather than on a live one.

Here we correct this check and also expand several debug assertions
that validated the detection of the claim style against the HTLC
type into full-blown assertions. If we end up hitting these,
they're almost certainly an indication that something has gone
horribly wrong and either keys have leaked or the node software is
confused and continuing would be unsafe.

Return `Err`s` instead of panicking on oversized messages

While this code should remain unreachable as it likely indicates
we're going to end up force-closing a channel due to being unable
to communicate with a peer, we shouldn't bring down the whole
process for it if we can avoid it.

Instead, at least return an `Err` so we can figure out what to do
with it in `PeerManager`.

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

Avoid panicking when attempting to send an oversized message

While this code should remain unreachable as it likely indicates
we're going to end up force-closing a channel due to being unable
to communicate with a peer, we shouldn't bring down the whole
process for it if we can avoid it.

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

Avoid oversized relayed failure messages

A downstream peer could send a maximum-sized update_fail_htlc
without attribution data. Adding attribution data while relaying the
failure made the message exceed the Noise framing limit and panic
during encryption.

Drop the attribution data again when adding it would push the relayed
failure over the wire limit, while preserving attribution for packets
that fit. The message length is derived from serialized_length on the
message and on the attribution data itself rather than from hardcoded
field sizes, which also lets us replace a stale assertion on the
maximum failure data length. Add a regression test for relaying a
maximum-sized failure and correct the existing size test to include
the message type.

Reported by Project Loupe.

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

Reject attempts to advance one-hop blinded forward paths

A malicious reply path can contain a single decryptable forward hop.
Advancing that path removed its only hop, causing onion construction to
panic when a handler attempted to respond.

Reject paths with fewer than two hops before attempting to advance
them. The regression test exercises the untrusted response path and
verifies that it returns an error without panicking.

Reported by Project Loupe.

Test written by: Elias Rohrer <dev@tnull.de>, which was
Co-Authored-By: HAL 9000

lightning-types: replace Zl/Zp separators in `PrintableString`

`PrintableString` replaces control (`Cc`), "other" (`C*`, including
`Cf`), and unassigned codepoints with U+FFFD, but U+2028 LINE SEPARATOR
(`Zl`) and U+2029 PARAGRAPH SEPARATOR (`Zp`) passed through verbatim:
`char::is_control` is `Cc`-only and the generated tables in
`unicode.rs` only cover the top-level `C` categories. Many terminals
and log viewers render U+2028/U+2029 as hard line breaks, so a
peer-controlled string (node alias, BOLT 12 description/issuer/
payer_note, `peer_msg`) could inject forged log lines that appear
sanitised.

Extend `contrib/gen_unicode_general_category.py` to also emit a
`Zl`/`Zp` separator predicate and regenerate `unicode.rs` from the
same UnicodeData 17.0.0 the existing tables were built from, then filter
on the new predicate in `PrintableString`. `Zs` is deliberately
excluded as it contains U+0020 SPACE. Add a regression test mirroring
the existing bidi-override test.

Found by a Loupe scan, tracked by the Bitcoin Security Council:
https://github.com/bitcoin-security-council/findings/pull/180

Co-Authored-By: goose (AI agent) <noreply@localhost>

Apply the unfunded channel peer limit to all unaccepted channels

If a peer floods us with channel requests, we previously failed to
enforce `MAX_UNFUNDED_CHANNEL_PEERS` as we considered the peer to
have some channels once it has more than one request pending.

Instead, we have to make sure we reject such channels by looking
at pending channels as well.

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

Allow filtered block rescans at the current tip

A valid same-block replay through Listen could panic OutputSweeper and
ChannelManager because both required every filtered_block_connected call
to advance the chain.

Treat callbacks matching the current tip as rescans, process their
additional transaction data, and skip the duplicate best-block update
while retaining chain-order checks for new blocks.

Fixes #3920

Reported by Project Loupe

Co-Authored-By: HAL 9000

Avoid panic when reorged claims cannot merge

Previously, a deep reorg could resurrect an HTLC package at a height
where it was no longer mergeable with its surviving claim. This caused
`OnchainTxHandler::blocks_disconnected` to panic on an assertion.

When merging fails, we now preserve the resurrected package in
`locktimed_packages` so normal block processing registers and broadcasts
it as an independent claim. Add a regression test covering the reorg and
subsequent broadcast.

Thanks to Kyle W. Santiago for reporting this issue.

Co-authored-by: Elias Rohrer <dev@tnull.de>

Update crate repository links to forgejo

Account for message type prefix len in prevtx length enforcement

Lightning wire messages have a maximum size of 65535 bytes, which
already accounts for the required two-byte message type prefix. Our
`TxAddInput::prevtx` length enforcement relied solely on the
`serialized_length` of the message, which does not account for the
prefix.

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.

bolt12: add pay_for_bolt12_invoice for externally-sourced invoices

Adds a new pay_for_bolt12_invoice method that pays a BOLT 12 invoice
without requiring it to have been requested through LDK. Unlike the
existing send_payment_for_bolt12_invoice, this method:

- Does not verify that the invoice was previously requested by LDK.
- Accepts a caller-supplied payment_id (no deduplication by invoice).
- Supports an optional partial amount_msats for multi-payer MPP flows,
where multiple senders each contribute a portion of the invoice total.
The onion total_msat is always set to the full invoice amount so the
recipient can validate the MPP payment correctly.

Also adds OptionalBolt12PaymentParams and Bolt12PaymentError, and
deprecates send_payment_for_bolt12_invoice and
manually_handle_bolt12_invoices in favour of the new flow.

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.

Correct docs on `ChannelSigner::get_per_commitment_point`

This was apparently missed in 1f7b24900d16c841d55fc83e0e2057e241d5e

ln: add ForwardToTrampoline tail and blinding in new_trampoline_entry

When we are forwarding as a trampoline within a blinded path, we need
to be able to set a blinding point in the outer onion so that
the next blinded trampoline can use it to decrypt its inner onion.

This is only used for relaying nodes in the blinded path, because the
introduction node's inner onion is encrypted using its node_id
(unblinded) pubkey so it can retrieve the path key from inside its
trampoline onion. Relaying nodes node_id is unknown to the original
sender, so their inner onion is encrypted with their blinded identity.
Relaying trampoline nodes therefore have to include the path key in the
outer payload so that the inner onion can be decrypted, which in turn
contains their blinded data for forwarding.

This isn't used for the case where we're the sending node, because all
we have to do is include the blinding point for the introduction node.
For relaying nodes, we just put their encrypted data inside of their
trampoline payload, relying on nodes in the blinded path to pass the
blinding point along.

When performing a trampoline forward we do not have a blinded tail,
because we've been given the next node's ID and have performed regular
pathfinding, so the final amount sits in the last hop's fee_msat and
there is no final value to set here. This is different to when we're
the original sender to a trampoline, because we have a blinded tail in
that case so only the fee is contained in the final hop.

ln/refactor: rename TrampolineEntry to SendToTrampoline

We construct our path differently for trampoline sends and forwards,
so we explicitly split this out.