rust-lightning

Merge PR 'Document that funding signing events can go stale' (#4960)

from bot/4951-fundingtransactionreadyforsignin-fa0568 into main

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

Drop the honggfuzz version pin from the CI fuzz job

The pin only ever existed because the job ran on our MSRV toolchain while
honggfuzz's own MSRV had moved past it, so each honggfuzz release broke
the job until someone picked an older version to install. With the job on
stable there is nothing left for the pin to guard: `cargo install
honggfuzz` and the `honggfuzz` 0.5 dependency the fuzz targets link
against both resolve to the current release, which is what we want to be
fuzzing with anyway.

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

Fixes #4968

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

Expose the dummy-hop tail constructor publicly

@matt asked on the diff:

> @auto-pr-bot this and the remining fns in this impl block shouldn't be
> crate-public.

@matt asked on the diff:

> @auto-pr-bot this should be public.

`BlindedPaymentPath::new_with_dummy_hops` is public, but the `DummyTlvs` it
takes could only be built by hand, leaving external callers to rederive the
per-hop constraint chaining themselves. Expose the constructor that does it,
and document what the returned upstream constraints are for.

The entropy source is only unused under `cfg(test)`, so name the parameter
rather than leaving an underscore-prefixed one in the public signature.

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

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4501#issuecomment-445043
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4501#issuecomment-445044

Fail commitment sig verification without counterparty params

@matt asked on the diff:

> @auto-pr-bot this example is adding nothing to public docs, please
> remove it.

@matt asked on the diff:

> Since this is now the "primary" error message we send to peers,
> @auto-pr-bot please change this to read "Received commitment sigs failed
> verification". Same for the version in `validate_commitment_signed`.

@matt asked on the diff:

> @auto-pr-bot just for extra belt-and-suspenders, can you add
> `debug_assert!(false);`, `log_error(...)` and a failure return if the
> `channel_transaction_parameters` is missing `counterparty_parameters`?
> Same for the similar code in `validate_commitment_signed`.

Verifying the counterparty's signatures on a holder commitment requires
their funding pubkey and selected contest delay, so with
`counterparty_parameters` unset we'd panic somewhere down in building the
commitment transaction. That should never happen, as we only accept
`commitment_signed` (initial or otherwise) once the counterparty's
parameters are known, but rather than risk a panic on a peer-driven path
we now log and close the channel. As on the other failure paths here, we
clear the funding outpoint for inbound channels first, so that we don't
broadcast a commitment for funding the counterparty may never publish.

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444803
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444937
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444942

Clarify the commitment validation failure message

@matt asked on the diff:

> @auto-pr-bot this example is adding nothing to public docs, please
> remove it.

@matt asked on the diff:

> Since this is now the "primary" error message we send to peers,
> @auto-pr-bot please change this to read "Received commitment sigs failed
> verification". Same for the version in `validate_commitment_signed`.

@matt asked on the diff:

> @auto-pr-bot just for extra belt-and-suspenders, can you add
> `debug_assert!(false);`, `log_error(...)` and a failure return if the
> `channel_transaction_parameters` is missing `counterparty_parameters`?
> Same for the similar code in `validate_commitment_signed`.

Now that no signature checking remains in channel, this error is what we
send our peer whenever the holder commitment they sent us fails to
validate - because their signatures don't verify, but also, e.g., because
the commitment has no outputs at all. Say so, rather than the vaguer
"Failed to validate our commitment", which reads as though the fault were
on our side.

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444803
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444937
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444942

Merge PR 'Drop stale splice signature on disconnect' (#4954)

from drop-stale-splice-sig-on-disconnect into main

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

Drop stale splice signature on disconnect

An initial splice `commitment_signed` can be buffered while waiting for
the user to provide funding signatures. While this was dropped after a
node restart as it's only intended to be live & in-memory state, it was
not dropped after a disconnection. This could lead to a duplicate
message being received after the negotiation has already completed,
leading to a force close.

This was discovered by the `chanmon_consistency` fuzzer via:

06a4721e111911191119401119407019bd411a1f0d91401119111911194070bec111b70e5df11611ffffffffffffffff411f0aa97210b6ff21b6ff5ba2ffad10

Merge PR 'offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice' (#4942)

from offer-key-can-sign-invoice into main

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

offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice

Follow-up to #4884 addressing Matt's naming nit.

Co-authored-by: Cursor <cursoragent@cursor.com>

Replace splice failure wire tests with a 0.2 downgrade test

@matt said:

> Feel free to squash.

@jkczyz said:

> Squashed

@matt asked:

> This is at least straightforward now. There's a lot of tests checking
> low-level serialization which I don't really buy as a way to test the
> 0.2 deserialization logic - if we want to test the 0.2 deserialization
> logic we need to actually use the 0.2 deserialization logic, not a copy
> of it using 0.3 types. Gonna go ahead and land this since the code is
> right and we need to get it over the line, but @auto-pr-bot can you
> replace the tests in events/mod.rs with tests in `lightning-tests` that
> use the 0.2 code to check the events? There's already some tests that do
> this in the PR so check that you're not duplicating coverage first.

@matt asked on the diff:

> I don't see the point of any of these tests. They feel like tests for
> tests sake rather than actually testing something meaningful.
> @auto-pr-bot

@matt asked on the diff:

> Same here. If we want to test upgrade/downgrade semantics the correct
> way is a `lightning-tests` multi-version test, not a test that checks
> the "wire" encoding of an `Event`.
>
> @auto-pr-bot

@matt asked on the diff:

> Yes, this is implied by the lack of implementation lol there's no need
> to document this @auto-pr-bot.

The `events` tests removed here built an `Event` by hand, wrote it, and
asserted on the bytes, or read bytes assembled to look like something
0.2 would have written. Either way they only ever exercised current
code's reader and writer, so they could not have caught a mismatch with
what 0.2 actually does -- the thing the encoding changes were about.
Checking that requires running 0.2's serialization, which is what
`lightning-tests` is for.

The reloads there already cover a splice failure releasing its whole
contribution, both for a negotiation aborted in flight and for one still
queued on quiescence, along with the `DiscardFunding` event type 0.2 has
to skip. What none of them cover is a contribution which reuses inputs
or outputs already committed to a pending splice: that is refused with
only the parts unique to it released, and those are what a downgraded
0.2 node has to learn about via `SpliceFailed`, since the
`DiscardFunding` carrying them is written under an event type it
ignores. Add a reload of a manager written with such a partial failure
pending, asserting 0.2 surfaces exactly the released output.

`FundingContribution::new_for_test` existed only to build contributions
for the removed tests, so it goes with them, as does the
`FailedSpliceContribution` note about having no serialization of its
own -- that is implied by the lack of any `Writeable`/`Readable`
implementation, so it tells callers nothing they need.

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

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442672
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442657
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442658
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442669

Document duplicate HTLC handling on revoked commitments

@matt said:

> Bitcoin red team flagged that if there's two HTLCs with identical
> `(payment_hash, amount)`s on a channel and the counterparty broadcasts a
> revoked commitment tx and then claims both we will only propagate the
> claim backwards on one of the two. This is, of course, not a
> "vulnerability" because we'll still get our money by taking our
> counterparty's funds via the revocation path, but it might be nice to
> claim both HTLCs cause, why not, free money.
>
> @auto-pr-bot can you do this? try to keep the code change small and
> contained, if its too big I'll respond in review and we'll switch to
> just leaving a comment instead.

@matt said:

> @auto-pr-bot try again.

@matt asked:

> Turned out to be way too much code. @auto-pr-bot can you instead just
> add a comment?

HTLC outputs on a revoked counterparty commitment transaction don't come
with an `HTLCSource`, so when one is spent we search the counterparty's
non-revoked commitment transactions for an HTLC with a matching
direction, payment hash and value. If a channel had two HTLCs which
share both a payment hash and a value, spends of either output match the
same first source.

Thus, if the counterparty claims both outputs with the preimage, we
propagate only one fulfillment upstream and fail the second upstream
HTLC, even though each matching upstream HTLC is independently claimable
once we have the preimage. Because the counterparty broadcasted a
revoked commitment we still recover the channel balance via the
revocation path, so this doesn't leave us out of pocket, but it does
give up an upstream claim we were entitled to.

Resolving the outputs against distinct sources means resolving every
matching source when a spend reveals a preimage and deterministically
matching duplicate outputs to sources otherwise, which is more than the
lookup here can do. Describe the behavior in a comment instead so the
next reader doesn't have to rediscover it.

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

Fixes #4904

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

Abort active splice RBF when prior candidate confirms

Rejecting new RBF attempts after confirmation does not cover an RBF
negotiation which began while the prior candidate was still unconfirmed.
When an earlier candidate confirms, inspect any active RBF and reset it
if is still safe and holder funding signatures have not been provided.
Propagate a structured abort through the chain-event path so
ChannelManager can notify a connected peer, fail any local contribution,
and release holding-cell updates. If signing has advanced too far,
retain the RBF until it completes, as splice promotion is blocked on its
completion.

Co-Authored-By: Codex <noreply@openai.com>

Clear pending signer state when aborting splice RBF

If an asynchronous signer blocks the initial commitment signature for an
RBF, aborting the `AwaitingSignatures` negotiation discards its signing
session but previously left `signer_pending_funding` set. A later
`signer_unblocked` callback would then retry signing funding state which
no longer exists.

Ignore messages from aborted splice negotiations

An aborted splice negotiation exits quiescence before the `tx_abort`
exchange has fully completed. An in-flight `interactive-tx` or
`commitment_signed` message for the discarded negotiation may therefore
arrive after the splice state has been removed, and treating them as
active-protocol violations can disconnect unnecessarily.

Ignore `interactive-tx` messages once the channel is no longer
quiescent, while retaining a warning disconnect for unexpected messages
received during quiescence. Check a single `commitment_signed` message's
funding txid before enforcing batch delivery so a signature for
discarded funding is ignored.

Disconnect on overlapping splice RBF negotiation

An inbound `tx_init_rbf` cannot identify a separate negotiation while
another funding negotiation is active. Sending `tx_abort` would
ambiguously abort the active negotiation and exit quiescence while
retaining its protocol state.

Return `WarnAndDisconnect` instead, preserving an `AwaitingSignatures`
negotiation for resumption across the disconnect rather than treating
the duplicate request as an abort. Remove the now-unused
NegotiationInProgress abort reason and update the existing
simultaneous-RBF regression coverage accordingly.

Add cross-version tests for queued splice failure events

A ChannelManager written with a splice contribution still queued
waiting on quiescence embeds synthesized failure events. Verify that a
downgraded 0.2 node reads such a manager and surfaces the failure as
its own SpliceFailed event carrying the contributed outputs, and that
a manager written by 0.2 with a queued splice -- which 0.2 persisted
in a legacy form current versions do not read -- loads with the queued
intent dropped and no events.

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 '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

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 '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>

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>