rust-lightning

Match renamed RBF-after-confirmation error in fuzz allow-list

@matt said on the diff:

> @auto-pr-bot can you fix this? @wpaulino says it looks like it should be
> this string now -
> https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/src/branch/main/lightning/src/ln/channel.rs#L13405
> and was broken in 274d09f1f71cdd6f272a03760755d86f39b0e7aa.

@matt said on the diff:

> @auto-pr-bot try again - base your change on the main branch as it
> should be an issue on main as well.

@matt asked on the diff:

> @auto-pr-bot try again.

`assert_disconnect_action` panics on any disconnect warning whose text it
doesn't recognize, matching each permitted case by substring. One entry
still carries the wording used before "Disallow splice RBF after candidate
confirmation" reworded `can_initiate_rbf`'s error to "A negotiated splice
transaction has already confirmed, cannot RBF", so it can no longer match
the message it was meant to permit. That rename only touched `channel.rs`,
leaving nothing to tie it back to the fuzz-side copy of the string.

Use the current wording so the entry describes a warning the code can
actually produce.

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

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

Say "confirmed" where splice RBF docs meant chain inclusion

A splice candidate stops being replaceable at its first confirmation,
while "locked" refers to the `splice_locked` exchange that promotes a
candidate to the channel's funding. Several docs described RBF
eligibility as lasting until the splice is "locked", which now reads as
allowing an RBF during the window between confirmation and promotion.

Reserve "locked" for the `splice_locked` markers and use "confirmed" for
chain inclusion. Wording about a queued contribution that genuinely waits
for the pending candidate to lock (and be promoted) is left as is.

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

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

Merge PR 'Fix silent merge conflict' (#4938)

from 2026-08-merge-conflict into main

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

Fix silent merge conflict

We had a silent merge conflict between some new splice tests and a
change to the splice events API.

Merge PR 'resource manager implementation' (#4409)

from elnosh/resource-mgr into main

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

Merge PR 'Disallow/abort splice RBF after splice candidate initial confirmation' (#4926)

from discard-ongoing-negotiation-on-splice-locked into main

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

Support retired TLV fields in object-constructing macros

The retired field type was initially limited to manual
`write_tlv_fields!`/`read_tlv_fields!`-style implementations because the
macros which construct the deserialized object (`impl_ser_tlv_based!`,
the enum macros, and `impl_writeable_msg!`) emit a struct literal or
match pattern naming every field, and a retired field has no backing
struct field to name.

Extend the `lightning-macros` filters that already drop `legacy` fields
from those positions to also drop `retired` fields, and route
`impl_writeable_msg!`'s constructed literal through the same filter,
which it previously bypassed. This lets any TLV field list mark a
retired type number rather than falling back to a manual implementation
just to reserve one.

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

Fold queued splice failures into on_restart_splice_failures

The reload path in `ChannelManager::write` had to know that a splice can
be dropped by a restart in two independent ways - an unpersisted funding
negotiation and a contribution queued waiting on quiescence - and chain
the two channel accessors itself. Collect both in a single channel
method instead, mirroring `maybe_fail_splice_negotiation` on the
force-close path, and name it after when the failures are surfaced
rather than after either individual source.

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

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

Merge PR 'Fail queued splice contributions on reload and force-close' (#4918)

from 2026-08-quiescent-action-persistence into main

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

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

Merge PR 'Fix cross-version serialization of splice failure events' (#4920)

from 2026-08-splice-event-tlv-compat into main

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

Merge PR 'Document duplicate HTLC handling on revoked commitments' (#4927)

from bot/4904-claim-both-sides-of-a-duplicate-263584 into main

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

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

Merge PR 'Redact ExpandedKey secret material from its Debug output' (#4900)

from bot/4899-redact-expandedkey-secret-materi-f1613b into main

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

Prune expired HTLCs prior to holding cell release on aborted splice RBF

Aborting an RBF from `transactions_confirmed` can release outbound
holding-cell updates immediately. Unlike the best-block path, this
callback did not first remove HTLCs which had become too close to
expiry, so an unsafe HTLC could be sent after the confirmation which
ended quiescence.

Extract holding-cell expiry pruning into a channel helper and call it
from both best-block and transaction-confirmation processing. Use the
greater of the callback height and current best-block height for
out-of-order callbacks, fail expired HTLCs backward before releasing the
holding cell, and only perform that release after startup background
events have been processed. Otherwise channel reestablishment will
release it once the channel is live.

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>

Disallow splice RBF after candidate confirmation

A splice candidate becomes non-replaceable at its first confirmation,
before `splice_locked` send or receive markers are necessarily set.
Using those later markers to decide RBF eligibility can allow outbound,
inbound, or queued RBF attempts to target a transaction which has
already confirmed. It can also cause a fresh splice requested during
this window to reuse the confirmed candidate as an RBF base.

Detect confirmation directly from the negotiated candidates and use that
state for local RBF initiation, queued-contribution eligibility, and
inbound `tx_init_rbf` validation. Return a fresh template without
prior-contribution or minimum-RBF metadata after confirmation so a new
splice waits behind the confirmed candidate instead of trying to replace
it.

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.

Fix tx_abort delivery in reconnect test helper

The second half of reconnect_nodes handles messages sent by node A to
node B, but tx_abort was delivered back to node A with node B as the
sender. This exercised the wrong state machine and could leave reconnect
tests with an incomplete abort exchange.

Fail queued splice contribution on force-close

A splice contribution committed via `funding_contributed` while a
counterparty-initiated funding negotiation is in progress is queued in
`quiescent_action` until the next quiescence session. If the channel
was force-closed in this state, the queued contribution was dropped
without emitting SpliceNegotiationFailed/DiscardFunding events, leaving
the user's contributed UTXOs locked with no signal to release them:
failing the active negotiation round and abandoning the queued action
were mutually exclusive on force-close.

Both may need reporting at once, e.g., a contribution folded into the
counterparty's round as the acceptor plus a second contribution queued
behind it, so ShutdownResult now carries any number of splice failures
and failure events are emitted for each.

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

Merge PR 'Drop `Arc<Self>` receiver in `read_all_channel_monitors_with_updates_parallel`' (#4921)

from parallel-updates-arc into main

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

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>

Fail queued splice contributions on ChannelManager reload

A splice contribution committed via `funding_contributed` sits queued
in the channel until quiescence is reached. Queued contributions are
not persisted, so restarting the node before then silently dropped
them, leaving the user unaware that their contributed UTXOs would
never be spent by a splice and could be reused.

`ChannelManager::write` already synthesizes `SpliceNegotiationFailed`
and `DiscardFunding` events for active negotiations in unpersisted
states. Synthesize them for queued contributions too, so a reloaded
node surfaces the failure and the user can reclaim the contributed
UTXOs and retry the splice.

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