rust-lightning

Merge PR 'Always populate `HTLCLocator::htlc_id` for outbound HTLCs' (#4917)

from bot/4912-add-htlc_id-s-to-htlclocator-679885 into main

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

Merge PR 'Generate the message fuzz binaries from the msg_targets module list' (#4922)

from bot/4896-msg_warning_message-fuzz-target-8d5bfe into main

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

Generate the message fuzz binaries from the msg_targets module list

The set of message types we fuzz was listed twice, once in
src/msg_targets/gen_target.sh, which generates the fuzz modules, and again
in src/bin/gen_target.sh, which turns those modules into the binaries
`ci-fuzz.sh` actually runs. Nothing checked that the two agreed, and they
did not: `WarningMessage` has had a module since it was introduced but was
never added on the binary side, so despite being parsed straight off the
wire it has never been in the fuzzing rotation.

Rather than adding the missing line, walk the modules that
src/msg_targets/gen_target.sh writes to mod.rs and generate one binary per
module, so a new message type only has to be listed in one place. The
regenerated output picks up msg_warning_message and reorders the message
entries in targets.h to match mod.rs.

Fixes #4896

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

@matt asked:

> @auto-pr-bot please go ahead and do this.

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/issues/4896#issuecomment-442241

Document how to de-duplicate `PaymentForwarded` events

We may generate more than one `PaymentForwarded` event for a single
forward when we do not yet know the fees we will pay to claim on-chain,
but we do not say what a handler should compare to spot the repeat.
Every such event describes the same inbound HTLCs, and those now always
carry the ID the inbound channel assigned them, so point handlers at
that as the key.

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

@matt asked on the diff:

> Hmm, instead, then, let's only provide the inbound `htlc_id`s and separate the `HTLCLocator` type between the source + dest. We should also update the `PaymentForwarded` event with a doc noting that `PaymentForwarded` events are unique across the set of inbound `ChannelId` + `htlc_id`s and should be de-duplicated with that as a key.

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4917#issuecomment-442231

Split `HTLCLocator` into inbound and outbound HTLC types

`HTLCLocator` was shared between the two sides of `PaymentForwarded`,
which forced every field to be documented in terms of both directions
and made `htlc_id` the odd one out: we always know the ID of the HTLC
which was forwarded to us, but for the HTLC we sent onwards the ID is
often unavailable. When the preimage comes from a chain transaction, or
when a claim is replayed from a `ChannelMonitor` on startup, all we have
is the HTLC's source, not the ID the outbound channel assigned it, and
once that channel is closed there is nowhere left to look it up.

Rather than teach the `ChannelMonitor` to track outbound HTLC IDs just
to fill the field in, drop it from the outbound side entirely. The
inbound IDs are enough to identify a forward, and each type can now
describe its fields for the one direction they are used in.

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

@matt asked on the diff:

> Hmm, instead, then, let's only provide the inbound `htlc_id`s and separate the `HTLCLocator` type between the source + dest. We should also update the `PaymentForwarded` event with a doc noting that `PaymentForwarded` events are unique across the set of inbound `ChannelId` + `htlc_id`s and should be de-duplicated with that as a key.

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4917#issuecomment-442231

Use retired for previously-retired TLV type numbers

Several TLV field lists documented a type number written by an old
release with only a comment, or tolerated it with a parse-and-discard
variable, and an audit of field lists across all release tags found
three more with no marker at all. Replace or mark these with retired
entries so the numbers are reserved against reuse.

The HTLCSource read list previously had no entry for its retired
type 3, and NodeInfo and PaymentClaimable parsed the old value only
to discard it; retired entries skip the bytes without requiring the
old value to parse. FixedPenaltyScorer data written by 0.0.105, the
only release to serialize its penalty, becomes readable again.
CommitmentTransaction's type 16 is reserved on the write side only,
so monitor data containing it keeps failing to read rather than
silently losing its anchors semantics.

Two numbers need no entry and are documented with comments: Channel
type 33 was written only by 0.0.116-alpha1, and
ChannelTransactionParameters type 12 was never written as `Some`
before 0.2 reused it.

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

Mark SpliceNegotiationFailed TLV types 3 and 9 retired

0.2 wrote `channel_type` and `abandoned_funding_txo` at types 3 and 9
of `Event::SpliceFailed`, which `Event::SpliceNegotiationFailed`
replaced. Reserve those numbers with retired entries in both the write
and read field lists instead of a comment, so reusing them fails to
build. Written bytes are unchanged, and events written by 0.2 read as
before.

The mid-negotiation upgrade test gains a variant that handles
`splice_ack` before 0.2 serializes, so the synthesized event carries
`channel_type` at type 3 and exercises the retired entries with real
0.2-written data.

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

Add a retired TLV field type reserving old type numbers

A TLV type number written by a previous release must not be reused
after its field is removed, as data serialized by that release would
be misparsed (see #4919). Until now the only record of such numbers
was code comments and ad-hoc parse-and-discard variables, which
nothing enforces.

Add a `retired` field type which keeps the number in the field list:
nothing is written, and on read any value present is ignored, so
retired even types written by a previous version no longer fail the
read. The entry participates in the encode-time ordering assertion,
so reusing the number trips it. Unlike `legacy`, which is for fields
still written for prior versions' benefit, retired fields never
appear in newly written data.

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

Write SpliceNegotiationFailed contributions for 0.2

When downgrading to 0.2 with a splice negotiation pending, the
synthesized `Event::DiscardFunding` containing the contribution is
ignored (see previous commit), leaving a 0.2 user without the set of
UTXOs freed by the abandoned negotiation.

0.2 read those UTXOs from the `contributed_inputs` and
`contributed_outputs` fields of `Event::SpliceFailed`, which it wrote
at TLV types 11 and 13 of event type 52. Write the inputs and outputs
released by the failure there too -- excluding any still committed to
an existing splice attempt -- so a downgraded node surfaces the same
event 0.2 would have written itself.

To that end, the event's `contribution` field is now an
`Option<FailedSpliceContribution>`, which holds the released inputs and
outputs alongside the `FundingContribution` available for retry. The
released inputs and outputs are also read back so that they survive
re-serialization.

Note that this makes a `ChannelManager` written with a splice failure
event pending unreadable by v0.3.0-beta1, which used those TLV types
for other fields.

Completes the fix for #4919.

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

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 'Reject shared inputs presented as owned' (#4905)

from reject-shared-input-as-owned-input into main

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

Merge PR 'Add `htlc_id`s to `HTLCLocator' (#4912)

from bot/4910-add-htlc_id-s-to-htlclocator-11407d into main

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

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>

Add `htlc_id`s to `HTLCLocator`

Expose the HTLC ID of each HTLC referenced by `PaymentForwarded` so that
callers can tie the event back to the individual HTLCs they previously
observed in `ChannelDetails::pending_{inbound,outbound}_htlcs`. Without
it there is no way to tell two in-flight HTLCs with the same payment
hash on the same channel apart.

The ID of an HTLC we received is always known, but the ID of the HTLC we
sent is only available when our counterparty settled it with an
`update_fulfill_htlc` message - when we instead extract the preimage
from an on-chain claim or replay a claim from our `ChannelMonitor`s on
startup we never learn which ID the outgoing HTLC had, so the field is
optional.

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

Fixes #4910

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

Merge PR 'Address review feedback on inline monitor storage key buffers' (#4908)

from bot/4869-build-monitor-storage-keys-witho-eae5a6 into main

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

Merge PR 'Avoid mutating pending events when serializing `ChannelManager`' (#4902)

from 2026-08-serialize-pending-events into main

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

Merge PR 'Automated change (2 commits)' (#4906)

from bot/4839-add-a-bolt-12-payer-proof-verifi-0fa979 into main

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

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 'Build monitor storage keys without allocating' (#4869)

from 2707-monitor-name-buffers into main

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

lightning-payer-proof: drop rustdoc the caller has no use for

`pays_offers_recipient` explained that it was written out against the
accessors LDK 0.3 exposes rather than calling a helper on `PayerProof`.
That is a note about how this crate is built, not something a caller has
to know or act on, and it goes stale the moment the helper lands.

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

lightning-payer-proof: drop the `std` feature

Nothing in the crate needs `std`: it is `no_std` plus `alloc` throughout,
and the feature only ever gated an `impl std::error::Error for
VerifyError` and `lightning/std`, neither of which changes what the crate
computes. Carrying it means every consumer, and every CI job, has one
more build configuration to think about for no gain.

`VerifyError` accordingly no longer implements `std::error::Error`;
`core::error::Error` is stable only from 1.81, above the 1.75 MSRV, so
there is nothing to replace it with here. `Display` is unchanged, and the
uniffi wrapper mirrors the enum with its own `std::error::Error` impl, so
bindings consumers see no difference.

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