rust-lightning

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.

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

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>

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

fuzz: allow empty-channel force close with in-flight payments

The chanmon harness can now force-close a target channel as long
as that channel itself has no pending HTLCs, even when another
channel still carries an in-flight payment. When an explicit close
succeeds, mark pending payments that routed over the closed channel
as allowed to fail.

This is the narrowest extension beyond globally HTLC-free closes. It
covers a payment that crossed one hop before its next, still-empty
channel is closed, without yet modeling force closes of channels that
themselves contain HTLCs. Route-aware failure tracking limits the
allowance to affected payments.

fuzz: require expected payment failures

Start pending payments at MustSucceed and require every tracked
PaymentFailed to follow an observed failure source. Cover receiver
rejection, corruption, local send failure, local inbound forwarding
failures, and the receive-side CLTV buffer.

Local inbound failures are classified when forwarding leaves an
inbound HTLC waiting for its removal revoke, before the failure can
reach the payer. For relayed failures, use
OutboundHTLCDetails::source to retain exact inbound channel and HTLC
IDs with the payment hash. This prevents same-hash MPP parts from
being mistaken for a local failure root.

fuzz: centralize payment send tracking

Rename the send-state query and local variables to describe whether LDK
still has pending work. Route the existing pending-payment registration
through one helper without changing which sends are tracked.

Later payment invariants must apply consistently to direct, forwarded,
and MPP sends. Centralizing this lifecycle decision keeps tracking
changes from diverging between send helpers.

fuzz: prepare payment failure tracking

Carry each send's minimum final CLTV expiry into payment
registration. Thread PaymentTracker through HTLC message delivery and
separate PaymentFailed from ProbeFailed dispatch.

A later invariant commit uses this context to classify failure roots.
Keeping the plumbing separate reduces its behavioral review even though
the minimum expiry remains temporarily unread.

fuzz: retain channel ids in payment paths

Keep each hop ChannelId beside its SCID and retain the complete set
of paths while a payment is pending. This is mechanical preparation;
the new fields are intentionally not interpreted yet.

SCIDs remain the route-building input, while explicit closes identify
channels by ChannelId. Carrying both representations in one path model
lets a later force-close allowance match affected payments without
reconstructing routes or maintaining parallel bookkeeping.

fuzz: derive routes from payment paths

Build direct, forwarded, and MPP routes from a shared per-path hop
description. Derive route fees and node metadata from that description,
and increase the CLTV delta by 100 for each successive hop.

Later failure tracking needs to describe the exact route that was sent.
Keeping route construction and bookkeeping on one representation
prevents them from drifting and prepares the tracker to retain more
per-hop failure context.