rust-lightning

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

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>

Correct docs on `ChannelSigner::get_per_commitment_point`

This was apparently missed in 1f7b24900d16c841d55fc83e0e2057e241d5e

Format changed functions

Change assign-reviewer authorized integration token to a bot acct

I didn't realize using my own authorized integration token would
result in every assignment being listed as coming from me, which is
weird so here we swap it for a bot.

Fixes #4804

Remove taproot build check

Bump esplora-client to 0.13 to switch from `reqwest` to `bitreq`

...fixing MSRV builds

Panic on unexpected chanmon monitor events

Monitor event draining expects BumpTransaction events, which the
harness must mine, plus SpendableOutputs and DiscardFunding events,
which it intentionally ignores because it does not model an external
wallet. Make that whitelist explicit by panicking on any other monitor
event instead of silently ignoring it.

fuzz: add a payer proof deserialization target

Throw arbitrary bytes at `PayerProof::try_from` to exercise the merkle-root
reconstruction and the deserialization path together.

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

Fix assign-reviewer's auth by setting the authorized integration audience

ci: don't double-assign reviewers, support manual assignment runs

The assign-reviewer workflow blindly picked a random reviewer every
time it ran, so a re-run (or any future non-opened trigger) could
request review from a second person even when someone was already on
the PR. Teach it to inspect the PR state first:

* Anyone already requested as a reviewer or who has submitted a
review is never picked. The author self-reviewing (commenting on
their own PR) doesn't count.
* On automatic runs (including re-runs), skip assignment entirely if
anyone from the REVIEWERS pool has already reviewed or been
requested; reviews from people outside the pool are ignored.

Also add a workflow_dispatch trigger taking a PR number so a reviewer
can be assigned manually. Manual runs skip the "someone is already on
it" check and always add a new (not-yet-involved) reviewer if an
eligible candidate remains.

This should let us fully emulate the old bot's second-reviewer
assignment logic fully via the action. A first reviewer can go hunt in
the actions page and trigger a second assignment (but we'll add a UI
element in the PR page above merge to trigger this in a nice UI).

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

Only emit Event::SpliceNegotiated when contributing

There's no need to inform users of negotiated splices when they're not
contributing as it just produces noise. Once they do start contributing,
they cannot stop, so we always emit the event going forward. Note that
we still emit `Event::ChannelReady` with the new locked funding outpoint
for each locked splice, so users can still learn that a splice occurred
that way.

Fix Joost's Forgejo username

Use the account name present on this Forgejo instance so Joost stays
in the reviewer rotation.

Co-Authored-By: HAL 9000

Fix lightning-invoice bitcoin dependency version

`lightning-invoice` since 743f43fcfd5acba55242792ed1e9337f2ab52858 will
not build against `rust-bitcoin` older than v0.32.7.

Add workflow to assign a random reviewer on new PRs

Forgejo has no built-in random/round-robin reviewer assignment, so add a
small Forgejo Actions workflow that, on pull request open, picks a random
developer from the maintainer pool (excluding the author) and requests
their review via the API.

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

Drop the BufReader wrapper

Post `0.32.4` deserialization of consensus objects now use `Read`
as the trait bounds, making the BufReader no longer needed for
deserialization.

Deserialize consensus objects using Read type

The BufReader wrapping is no longer needed after the rust-bitcoin
`0.32.4` release which contains the standardisation of the trait
bounds for deserialization to `Read` instead of `BufReader`.

Drop duplicate Hasher import

Avoid over-allocating when reading corrupted lengths for `HashMap`s

Luckily this was only used in `ChannelManager` and scorer
deserialization, though we anticipate occasionally fetching the
second from an only semi-trusted source.

Fix invalid dummy pubkey in send_to_route

If a caller of send_payment_with_route provided a route with either no paths,
or where the first path had 0 hops, the method would panic due to attempting to
unwrap a dummy pubkey that was initialized with 32 bytes instead of the
required 33.

Reported by Project Loupe.

Correct deserialization of `u16::MAX` byte-Features

This shouldn't really matter in practice, but it aligns the
serialization and deserialization logic.

Reported by Project Loupe.

Don't panic when a composite sub-handler returns `Ok(None)`

A handler built with `composite_custom_message_handler!` routes an incoming
message type to the sub-handler whose pattern matches it and assumed the
sub-handler would always decode it. But per the `CustomMessageReader`
contract a sub-handler returns `Ok(None)` for a type it doesn't recognize,
and a sub-handler's pattern -- a range in particular -- can be broader than
the types it actually decodes.

Since the message type comes from peer input, this let a remote peer panic
the message-processing thread with a single custom message whose type falls
in a sub-handler's pattern but isn't decoded by it. Report such a message as
unknown instead, matching how `wire::do_read` handles an undecoded custom
message.

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

Treat replayed LSPS2 HTLCs idempotently

Replayed intercepted HTLC events should not duplicate queued payments or
panic after restart. Ignore already-queued intercept IDs so persisted
queues remain stable across event replay.

Co-Authored-By: HAL 9000