Skip to content

Splice with mempool fuzz fixes#4708

Open
wpaulino wants to merge 6 commits into
lightningdevkit:mainfrom
wpaulino:splice-with-mempool-fuzz-fixes
Open

Splice with mempool fuzz fixes#4708
wpaulino wants to merge 6 commits into
lightningdevkit:mainfrom
wpaulino:splice-with-mempool-fuzz-fixes

Conversation

@wpaulino

Copy link
Copy Markdown
Contributor

This PR includes a few more bug fixes that were discovered by the chanmon_consistency_target after #4657.

Fixes #4696.

@wpaulino wpaulino added this to the 0.3 milestone Jun 17, 2026
@wpaulino wpaulino requested a review from jkczyz June 17, 2026 18:38
@wpaulino wpaulino self-assigned this Jun 17, 2026
@ldk-reviews-bot

ldk-reviews-bot commented Jun 17, 2026

Copy link
Copy Markdown

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@ldk-claude-review-bot

ldk-claude-review-bot commented Jun 17, 2026

Copy link
Copy Markdown
Collaborator

I have re-verified the key changes against the actual code. Everything is consistent with my prior review:

  • validate_tx_init_rbf reordering (channel.rs:13390-13438) behaves as expected; the no-candidate + negotiation-in-progress edge only changes the abort message, both paths abort.
  • The fuzz allowlist addition for "contribution no longer valid at quiescence" correctly matches the still-WarnAndDisconnect re-validation path at channel.rs:14656.
  • has_local_contribution gating, the splice_funding_failed_for! macro refactor, the new AbortReason variants, and the from_chan_no_close .clone() change are all consistent and correct.

No issues found.

wpaulino added 6 commits June 17, 2026 14:22
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.
Previously, this could result in an acceptor not receiving a
`Event::SpliceNegotiationFailed` for a splice in which they reused the
same contribution (except for the feerate change). Our API should
guarantee that users should always see `SpliceNegotiated` and
`SpliceNegotiationFailed` events for splices that they contribute to.
While a contribution may be valid at the time the splice is requested,
quiescence still needs to happen, which can affect the balances of the
channel as it fully settles all pending state. After doing so, it's
possible that the contribution is no longer valid. Since quiescence
itself doesn't have a terminal message, we see a `WarnAndDisconnect`
event happen.
We keep some `WarnAndDisconnect` cases as mandated by the spec, but
otherwise prefer sending `tx_abort` to terminate quiescence and avoid
reconnection loops.
Send `tx_abort` to terminate quiescence and avoid reconnection loops.
This mirrors what we do for counterparty `splice_init` messages, making
sure we don't accept RBFs once a channel has requested shutdown.
@wpaulino wpaulino force-pushed the splice-with-mempool-fuzz-fixes branch from bc23128 to a120ac1 Compare June 17, 2026 21:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Splice negotiation failure handling issues

3 participants