rust-lightning

Merge PR 'Fix unused warning on `do_test_splice_revalidation_at_quiescence`' (#4863)

from 2026-08-unused-error into main

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

Fix unused warning on do_test_splice_revalidation_at_quiescence

This caused CI failures on some cargo 1.75 jobs.

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.

Add release notes for LDK 0.2.5

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.

Fix blinded fee calculation for over-100% proportional fees

`amt_to_forward_msat` calculates the fee before conditionally
decrementing the forwarded amount, then asserts that the forwarded
amount and the stale fee sum to the inbound amount. Nothing bounds a
blinded path's `fee_proportional_millionths` to 1_000_000, and above
that each additional msat forwarded costs us more than one msat in
fee, so decrementing by a single msat cannot restore the invariant.

A forwarding node applies the `payment_relay` from the blinded path
verbatim to the inbound HTLC amount, so an `update_add_htlc` whose
amount does not correspond to any amount the path's own fee schedule
would produce trips the assertion. `BlindedPaymentPath::new` trips it
too when calculating a path's `htlc_maximum_msat`.

Round the forwarded amount down instead, and only increase it if the
fee we retain still covers the fee we require. This returns identical
values for every `fee_proportional_millionths` at or below 1_000_000,
so behavior on an honest path is unchanged. Release builds always
retained at least the required fee, so only the assertion was wrong.

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