rust-lightning

Write DiscardFunding contributions as an odd event type

`FundingInfo::Contribution` was added in 0.3, but 0.2 fails to read
unknown `FundingInfo` variants. A `ChannelManager` or `ChannelMonitor`
serialized while an `Event::DiscardFunding` containing one was pending
-- the former whenever serialized during an incomplete splice
negotiation with a local contribution, the latter upon discarding a
negotiated splice with a recorded contribution -- could therefore never
be read by 0.2.

Write such events under a new odd event type, which prior versions
ignore, restoring the ability to downgrade. A downgraded node loses the
event; the next commit compensates for the negotiation-failure case by
including the discarded UTXOs in `Event::SpliceNegotiationFailed`.

Partially addresses #4919.

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

Fix SpliceNegotiationFailed TLV collision with 0.2

`Event::SpliceFailed` was released in 0.2 writing `contributed_inputs`
and `contributed_outputs` at TLV types 11 and 13. When those fields
were removed, the freed types were reused for the new `reason` and
`contribution` fields of the renamed `Event::SpliceNegotiationFailed`.

Consequently, a `ChannelManager` written by 0.2 while such an event was
pending -- the case whenever one is serialized during an incomplete
splice negotiation with a local contribution -- fails to read on 0.3,
as the legacy fields are misparsed as the new ones. Conversely, 0.2
fails to read a `ChannelManager` written by 0.3 while such an event was
pending.

Write `reason` and `contribution` at fresh odd TLV types, restoring the
compatibility behavior documented when the fields were removed; the
legacy types are odd, so unknown-type handling skips them on read. Note
that a `ChannelManager` written by v0.3.0-beta1 while such an event was
pending is no longer readable, as beta1 wrote `reason` and
`contribution` at the colliding types.

Partially addresses #4919; a pending `Event::DiscardFunding` with
`FundingInfo::Contribution` still prevents downgrade to 0.2.

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

Merge PR 'Defer splice_locked during RBF signing' (#4891)

from delay-splice-promotion-inflight-rbf-negotiation into main

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

Merge PR 'Checkpoint deferred ChannelManager with AwaitingSignatures splice' (#4911)

from fuzz-checkpoint-splice-signing-session into main

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

Checkpoint deferred ChannelManager with AwaitingSignatures splice

We don't currently checkpoint our signing session prior to sending
`commitment_signed`. The fuzzer has shown that it's possible that we
commit to a splice candidate and reload with an outdated manager prior
to the signing session existing. If the counterparty commits to the
splice back, and is expecting to resume, we'll end up aborting
erroneously leading to a force close. We defer the real fix for now and
instead prevent the fuzzer from running into this case.

Fixes fuzz payload:

7f0200000000004211a10081bd4a191f1119401f001118100f1810411f00111810101b10401f00111810101810411f00111810101810401f00111fb170b170ff

tx-sync: parallelize esplora status queries

The esplora sync loop awaited each HTTP query sequentially: one
get_block_status per relevant txid, 3 round trips (merkle block, tx,
block status) per watched transaction, and one get_output_status per
watched output. With many channels this pure latency dominates sync
wall-clock time, particularly during the first sync after a restart.

In async builds, run the per-block, per-transaction, and per-output
queries concurrently via buffer_unordered, bounded at 16 in-flight
requests by default and configurable via with_concurrency.
Confirmed transactions are already sorted by (height, in-block
position) before being fed to the confirmables, so completion order
does not matter. The blocking client variant remains sequential.

Also dedup block status queries by block hash (multiple relevant txids
can share a block), and drop a redundant duplicate-txid check when
iterating watched_transactions: it is a HashSet, so txids are unique.

Note that items are moved into the concurrently-polled futures as owned
values (txids copied, watched outputs cloned). Borrowing them compiles
within this crate but trips rustc's "implementation of FnOnce is not
general enough" false positive in downstream callers that box the
returned sync future.

lightning-payer-proof: flag the uniffi record's untrusted strings

The uniffi record hands its three free-text fields back as plain
`String`s, copied straight out of the proof with no sanitization, but
only `offer_description` warned about that. `offer_issuer` and
`proof_note` are just as attacker-controlled, so carry the same warning
on both.

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

Merge PR 'Add a BOLT 12 payer proof verification crate' (#4839)

from lightning-payer-proof into main

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

Merge PR 'Ban non-dust HTLCs if dust limit would be breached' (#4890)

from 2026-08-ban-nondust-htlcs into main

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

Fix outdated PersistenceNotifierGuard comment

Correct 0.2.5 and 0.1.12 CHANGELOG entries

* The response panic issue is when accepting *onion messages*
which merit a response, not HTLCs,
* 0.1 was not vulnerable to the panic-on-reorg issue Kyle reported
as it did not contain the new package merging logic.

Add 0.1.12 release notes

Merge PR 'Fix warnings on `nightly`' (#4864)

from 2026-08-fix-nightly-warnings into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4864
Reviewed-by: tankyleo <tankyleo@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