Wipe splice state upon failed interactive funding construction #4120

wpaulino · 2025-09-24T19:40:26Z

An interactive funding construction can be considered failed upon a disconnect or a tx_abort message. So far, we've consumed the InteractiveTxConstructor in the latter case, but not the former. Additionally, we may have splice-specific state that needs to be consumed as well to allow us to negotiate another splice later on.

This commit ensures that we properly consume all splice and interactive funding state whenever possible upon a disconnect or tx_abort.

The interactive funding state is safe to consume as long as we have either yet to reach AwaitingSignatures, or we have but tx_signatures has not been sent/received.

The splice state is safe to consume as long as we don't have a pending FundingNegotiation::AwaitingSignatures with a tx_signatures sent/received and we don't have any negotiated candidates. Note that until splice RBF is supported, it is not currently possible to have any negotiated candidates with a pending interactive funding transaction.

ldk-reviews-bot · 2025-09-24T19:40:28Z

👋 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.

codecov · 2025-09-24T20:02:24Z

Codecov Report

❌ Patch coverage is 76.78571% with 52 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.65%. Comparing base (3e21ba3) to head (a5dcdc1).
⚠️ Report is 72 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	40.90%	51 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4120      +/-   ##
==========================================
- Coverage   88.72%   88.65%   -0.07%     
==========================================
  Files         177      180       +3     
  Lines      133404   135086    +1682     
  Branches   133404   135086    +1682     
==========================================
+ Hits       118365   119767    +1402     
- Misses      12325    12557     +232     
- Partials     2714     2762      +48

Flag	Coverage Δ
fuzzing	`21.76% <21.59%> (+0.03%)`	⬆️
tests	`88.50% <76.78%> (-0.07%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

jkczyz · 2025-09-25T16:08:49Z

lightning/src/ln/channel.rs

+						signing_session.holder_tx_signatures().is_some()
+							|| signing_session.has_received_tx_signatures()


Does it matter if we received their signatures if we haven't sent ours? Or is it because if they sent theirs then they would not have reset their state?

You're supposed to remember the channel as soon as one side has sent tx_signatures, because you can't be sure the other side didn't just sign and broadcast without sending their own.

lightning/src/ln/channel.rs

ldk-reviews-bot · 2025-09-25T16:29:10Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

jkczyz · 2025-09-25T20:34:23Z

lightning/src/ln/channel.rs

-					.pending_splice
-					.as_mut()
-					.and_then(|pending_splice| pending_splice.funding_negotiation.take());
+				if funded_channel.should_reset_pending_splice_funding_negotiation() {


Looks like we aren't calling fail_interactive_tx_negotiation when failing to handle a splice_ack. #4077 updates fail_interactive_tx_negotiation to take a NegotiationError, which it uses to construct a SpliceFundingFailed struct.

For FundingNegotiation::ConstructingTransaction, the NegotiationError is formed by copying the inputs from the InteractiveTxConstructor. For FundingNegotiation::AwaitingAck when handling splice_ack, we'd need to do something similar?

Either way we are cloning the inputs just to later take the FundingNegotiation here. Maybe that is ok for now? Any thoughts on a better way of doing this?

Hmmm... so we are also already take'ing the FundingNegotiation in one place in splice_ack handling (when FundingNegotiation::into_interactive_tx_constructor fails), but not earlier when validating the splice_ack message.

We shouldn't need to call fail_interactive_tx_negotiation whenever we fail handling a message by sending a warning and disconnecting.

Ah, so failing to process a splice_ack would just disconnect, and the peer could re-send it after reconnecting. Do we eventually timeout quiescence somewhere?

Quiescence is also implicitly terminated upon disconnection, but we do have a timeout enforced at should_disconnect_peer_awaiting_response.

Oh, so we'd need to produce a SpliceFailed event in some other way? I'm thinking when we are in FundingNegotiation::AwaitingAck and fail processing the splice_ack.

Yeah sounds like that logic might need to live in the disconnection handler, since we'll need to emit an event anyway if a peer disconnects mid-splice negotiation for whatever reason.

lightning/src/ln/channel.rs

An interactive funding construction can be considered failed upon a disconnect or a `tx_abort` message. So far, we've consumed the `InteractiveTxConstructor` in the latter case, but not the former. Additionally, we may have splice-specific state that needs to be consumed as well to allow us to negotiate another splice later on. This commit ensures that we properly consume all splice and interactive funding state whenever possible upon a disconnect or `tx_abort`. The interactive funding state is safe to consume as long as we have either yet to reach `AwaitingSignatures`, or we have but `tx_signatures` has not been sent/received. In all of these cases, we also make sure to clear the quiescent state flag such that we're able to resume processing updates on the channel. The splice state is safe to consume as long as we don't have a pending `FundingNegotiation::AwaitingSignatures` with a `tx_signatures` sent/received and we don't have any negotiated candidates. Note that until splice RBF is supported, it is not currently possible to have any negotiated candidates with a pending interactive funding transaction.

jkczyz · 2025-09-27T18:20:55Z

lightning/src/ln/channel.rs

+						signing_session.holder_tx_signatures().is_some()
+							|| signing_session.has_received_tx_signatures()


Shouldn't this be negated? If either side has exchanged signatures then we don't want to reset?

jkczyz · 2025-09-27T18:22:47Z

lightning/src/ln/channel.rs

+					funded_channel.context.channel_state.clear_quiescent();
+					funded_channel
+						.pending_splice
+						.as_mut()
+						.and_then(|pending_splice| pending_splice.funding_negotiation.take());


Should we also clear interactive_tx_signing_session if in FundingNegotiation::AwaitingSignatures and we haven't sent/received signatures?

jkczyz · 2025-09-27T18:40:58Z

lightning/src/ln/channel.rs

+			}
+		}
+
+		if self.should_reset_pending_splice_funding_negotiation().unwrap_or(false) {


Why use unwrap_or(false) here but fail_interactive_tx_negotiation uses true?

jkczyz · 2025-09-27T18:54:23Z

lightning/src/ln/channel.rs

+			if self.pending_splice.is_none() {
+				// If we were in quiescence but a splice was never negotiated, we shouldn't be
+				// quiescent anymore upon reconnecting.
+				self.context.channel_state.clear_quiescent();


Don't we always want to clear quiescence upon disconnect?

jkczyz · 2025-09-27T18:56:02Z

lightning/src/ln/channel.rs

+			self.pending_splice
+				.as_mut()
+				.and_then(|pending_splice| pending_splice.funding_negotiation.take());


FWIW, I have this in a different function in #4077 since I need to funding_negotiation to produce a SpliceFailed, but I should be able to move it there.

jkczyz · 2025-09-27T18:58:04Z

lightning/src/ln/channel.rs

+						if funded_channel.should_reset_pending_splice_state() {
+							funded_channel.pending_splice.take();
+						}


should_reset_pending_splice_state calls should_reset_pending_splice_funding_negotiation again, but the latter is partly determined based on pending_splice.funding_negotiation, which is taken above. Everything seems to check out for the second call based on how unwrap_or is used, but that feels kinda fragile.

Wondering if instead of using two different methods, we could do something like:

fn maybe_reset_splice_funding_negotation(&mut self) -> Option<SpliceFundingFailed> { // ... }

This would clear pending_splice.funding_negotiation, pending_splice, and interactive_tx_signing_session, as appropriate and convert them to the SpliceFundingFailed needed to produce a SpliceFailed event.

wpaulino added this to the 0.2 milestone Sep 24, 2025

wpaulino requested a review from jkczyz September 24, 2025 19:40

wpaulino self-assigned this Sep 24, 2025

jkczyz reviewed Sep 25, 2025

View reviewed changes

wpaulino force-pushed the reset-splice-state branch from e418d45 to 92c7ff4 Compare September 25, 2025 21:08

jkczyz reviewed Sep 25, 2025

View reviewed changes

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

wpaulino force-pushed the reset-splice-state branch from 92c7ff4 to c95b678 Compare September 25, 2025 23:00

wpaulino requested review from jkczyz and TheBlueMatt September 26, 2025 03:17

jkczyz previously approved these changes Sep 26, 2025

View reviewed changes

TheBlueMatt reviewed Sep 26, 2025

View reviewed changes

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

TheBlueMatt reviewed Sep 26, 2025

View reviewed changes

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

wpaulino dismissed jkczyz’s stale review via a5dcdc1 September 26, 2025 18:33

wpaulino force-pushed the reset-splice-state branch from c95b678 to a5dcdc1 Compare September 26, 2025 18:33

wpaulino requested review from TheBlueMatt and jkczyz September 26, 2025 18:34

TheBlueMatt approved these changes Sep 26, 2025

View reviewed changes

jkczyz reviewed Sep 27, 2025

View reviewed changes

		signing_session.holder_tx_signatures().is_some()
		\|\| signing_session.has_received_tx_signatures()

Wipe splice state upon failed interactive funding construction #4120

Are you sure you want to change the base?

Wipe splice state upon failed interactive funding construction #4120

Conversation

wpaulino commented Sep 24, 2025

Uh oh!

ldk-reviews-bot commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ldk-reviews-bot commented Sep 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkczyz Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ldk-reviews-bot commented Sep 24, 2025 •

edited

Loading

codecov bot commented Sep 24, 2025 •

edited

Loading

jkczyz Sep 25, 2025 •

edited

Loading