Splice channel state rework #4061

wpaulino · 2025-09-05T22:53:13Z

This was pulled out of #4054 to ease review. It depends on #4060 to not bother with cfg(splicing) anymore.

ldk-reviews-bot · 2025-09-05T22:53:17Z

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

graphite-app · 2025-09-05T23:06:46Z

lightning/src/ln/channel.rs

+			// FIXME: Either we bring back the `OUR_TX_SIGNATURES_READY` flag for this specific
+			// case, or we somehow access the signing session to check it instead.
+			ChannelState::FundingNegotiated(flags) => !flags.is_interactive_signing(),


The current implementation has a potential logic issue. The FIXME comment correctly identifies that is_interactive_signing() is being used as a replacement for the removed OUR_TX_SIGNATURES_READY flag, but these represent different states:

is_interactive_signing() is true during the entire interactive signing process

OUR_TX_SIGNATURES_READY was specifically true only after our signatures were ready to send

This semantic difference could cause funding transactions to be incorrectly marked as non-broadcastable when they should be broadcastable. Consider either:

Restoring the OUR_TX_SIGNATURES_READY flag for this specific use case, or

Accessing the signing session directly to check if holder signatures are ready via something like signing_session.holder_tx_signatures().is_some()

This would more accurately represent the original intent of the code.

Suggested change

// FIXME: Either we bring back the `OUR_TX_SIGNATURES_READY` flag for this specific

// case, or we somehow access the signing session to check it instead.

ChannelState::FundingNegotiated(flags) => !flags.is_interactive_signing(),

// We need to check if our signatures are ready to send, which means the transaction

// is ready to be broadcast.

ChannelState::FundingNegotiated(flags) => {

if let Some(signing_session) = &self.funding_tx_signing_session {

signing_session.holder_tx_signatures().is_none()

} else {

!flags.is_interactive_signing()

}

},

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

ldk-reviews-bot · 2025-09-08T00:00:40Z

🔔 1st Reminder

Hey @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

codecov · 2025-09-08T22:03:51Z

Codecov Report

❌ Patch coverage is 35.00000% with 91 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.84%. Comparing base (867f084) to head (8ca96e3).
⚠️ Report is 12 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	34.58%	85 Missing and 2 partials ⚠️
lightning/src/ln/interactivetxs.rs	0.00%	3 Missing ⚠️
lightning/src/ln/channelmanager.rs	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4061      +/-   ##
==========================================
- Coverage   88.39%   87.84%   -0.55%     
==========================================
  Files         177      176       -1     
  Lines      131314   131310       -4     
  Branches   131314   131310       -4     
==========================================
- Hits       116069   115348     -721     
- Misses      12596    13333     +737     
+ Partials     2649     2629      -20

Flag	Coverage Δ
fuzzing	`21.63% <10.71%> (-0.38%)`	⬇️
tests	`87.67% <35.00%> (-0.55%)`	⬇️

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.

graphite-app · 2025-09-09T20:15:12Z

lightning/src/ln/channel.rs

+				debug_assert!(
+					false,
+					"A signing session must always be present while interactive signing"
 				);
+				let err =
+					format!("Channel {} not expecting funding signatures", self.context.channel_id);
 				return Err(APIError::APIMisuseError { err });


The code contains a pattern where a debug assertion claims a signing session must always be present during interactive signing, but then includes error handling for when it's None. This creates a logical contradiction - either:

The assertion is correct and the error handling is unnecessary, or

The error handling is necessary and the assertion is incorrect

This pattern appears multiple times throughout the code. Consider either:

Removing the error handling if the assertion truly holds

Adjusting the assertion to reflect the actual conditions where a signing session might be absent

This would make the code's intent clearer and avoid potential confusion about the expected state during interactive signing.

Suggested change

debug_assert!(

false,

"A signing session must always be present while interactive signing"

);

let err =

format!("Channel {} not expecting funding signatures", self.context.channel_id);

return Err(APIError::APIMisuseError { err });

// A signing session should typically be present during interactive signing,

// but handle the case where it's not

let err =

format!("Channel {} not expecting funding signatures", self.context.channel_id);

return Err(APIError::APIMisuseError { err });

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

ldk-reviews-bot · 2025-09-11T19:58:57Z

🔔 1st Reminder

Hey @TheBlueMatt @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-09-11T19:58:59Z

🔔 1st Reminder

Hey @TheBlueMatt @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt

Will have to finish looking later

lightning/src/ln/channel.rs

TheBlueMatt · 2025-09-11T19:25:50Z

lightning/src/ln/channel.rs

@@ -8655,56 +8642,51 @@ where
 	#[rustfmt::skip]
 	pub fn tx_signatures(&mut self, msg: &msgs::TxSignatures) -> Result<(Option<msgs::TxSignatures>, Option<Transaction>), ChannelError> {
 		if !self.context.channel_state.is_interactive_signing()
-			|| self.context.channel_state.is_their_tx_signatures_sent()
+			&& !self.has_pending_splice_awaiting_signatures()


Those are the only two states when we should be processing an incoming tx_signatures.

jkczyz · 2025-09-11T16:29:21Z

lightning/src/ln/channel.rs

+			// FIXME: Either we bring back the `OUR_TX_SIGNATURES_READY` flag for this specific
+			// case, or we somehow access the signing session to check it instead.


Should we move this out of ChannelContext then?

Either that, or we track the session in the context, which lets us get rid of the interactive signing flag. I'm leaning towards the latter.

or we track the session in the context, which lets us get rid of the interactive signing flag

Pushed an update that ended up doing this.

lightning/src/ln/channel.rs

jkczyz · 2025-09-11T20:29:47Z

lightning/src/ln/channel.rs

+			self.channel_state,
+			ChannelState::ChannelReady(f) if f.is_set(ChannelReadyFlags::QUIESCENT)
+		);
+		debug_assert!(self.channel_state.is_interactive_signing() || is_quiescent);


For v2-channel establishment, is_quiescent isn't applicable, IIUC. But for splicing, wouldn't checking is_interactive_signing be sufficient?

The interactive signing flag is only relevant to dual funding due to it being a flag on ChannelState::FundingNegotiated.

The tests have become a bit painful to maintain, and they don't even fully test the production code paths, so we opt to just remove them for now. In the future, we plan to unify the dual funding code paths with splicing.

Since the `InteractiveTxSigningSession` already tracks everything we need, we can remove the duplicate interactive signing state tracking within `ChannelState`.

This commit addresses an overlap of state between `InteractiveTxSigningSession` and `ChannelState::FundingNegotiated`. The signing session already tracks whether both holder and counterparty `tx_signatures` have been produced, so tracking the state duplicatively at the `ChannelState` level is unnecessary.

Once a channel open has become locked (i.e., we've entered `ChannelState::ChannelReady`), the channel is intended to remain within this state for the rest of its lifetime until shutdown. Previously, we had assumed a channel being spliced would go through the `ChannelState` lifecycle again starting from `NegotiatingFunding` but skipping `AwaitingChannelReady`. This inconsistency departs from what we strive to achieve with `ChannelState` and also makes the state of a channel harder to reason about. This commit ensures a channel undergoing a splice remains in `ChannelReady`, clearing the quiescent flag once the negotiation is complete. Dual funding is unaffected by this change as the channel is being opened and we want to maintain the same `ChannelState` lifecycle.

jkczyz

LGTM other some minor fixes

jkczyz · 2025-09-12T19:20:55Z

lightning/src/ln/channel.rs

+					pending_splice.funding_negotiation.take()
+				{
+					funding.funding_transaction = funding_tx_opt.clone();
+					self.pending_funding.push(funding);


Oh, did we not do this yet?

jkczyz · 2025-09-12T19:22:02Z

lightning/src/ln/channel.rs

+			if let Some(pending_splice) = self.pending_splice.as_mut() {
+				if let Some(FundingNegotiation::AwaitingSignatures(mut funding)) =
+					pending_splice.funding_negotiation.take()
+				{
+					funding.funding_transaction = funding_tx_opt.clone();
+					self.pending_funding.push(funding);
+				} else {
+					debug_assert!(false, "We checked we were in the right state above");
+				}
+				self.context.channel_state.clear_quiescent();
+			} else {
+				self.funding.funding_transaction = funding_tx_opt.clone();
+				self.context.channel_state =
+					ChannelState::AwaitingChannelReady(AwaitingChannelReadyFlags::new());
+			}


nit: Might be worth DRYing this up

jkczyz · 2025-09-12T19:23:42Z

lightning/src/ln/channel.rs

+		#[cfg(debug_assertions)]
+		let sent_or_received_tx_signatures = self


CI is sad. Can't seem to see this for check_release.

jkczyz · 2025-09-12T19:26:29Z

lightning/src/ln/channelmanager.rs

-		) -> (Option<MonitorUpdateCompletionAction>, Option<RAAMonitorUpdateBlockingAction>),
+		)
+			-> (Option<MonitorUpdateCompletionAction>, Option<RAAMonitorUpdateBlockingAction>),


CI isn't happy here and below. Think I've seen this sometimes where rustfmt is nondeterministic.

ldk-reviews-bot requested a review from valentinewallace September 5, 2025 23:03

graphite-app bot reviewed Sep 5, 2025

View reviewed changes

wpaulino removed the request for review from valentinewallace September 8, 2025 20:42

wpaulino force-pushed the splice-channel-state-rework branch from 9272b39 to 23a1c29 Compare September 8, 2025 21:49

wpaulino requested review from TheBlueMatt and jkczyz September 9, 2025 19:58

wpaulino self-assigned this Sep 9, 2025

wpaulino added this to the 0.2 milestone Sep 9, 2025

wpaulino force-pushed the splice-channel-state-rework branch from 23a1c29 to 0cbeb51 Compare September 9, 2025 19:59

graphite-app bot reviewed Sep 9, 2025

View reviewed changes

TheBlueMatt reviewed Sep 11, 2025

View reviewed changes

jkczyz reviewed Sep 11, 2025

View reviewed changes

wpaulino added 4 commits September 11, 2025 17:08

Remove incomplete dual funding tests

3a05947

The tests have become a bit painful to maintain, and they don't even fully test the production code paths, so we opt to just remove them for now. In the future, we plan to unify the dual funding code paths with splicing.

Move interactive signing session into ChannelContext

f3ee251

Since the `InteractiveTxSigningSession` already tracks everything we need, we can remove the duplicate interactive signing state tracking within `ChannelState`.

wpaulino force-pushed the splice-channel-state-rework branch from 0cbeb51 to 8ca96e3 Compare September 12, 2025 00:12

wpaulino requested review from TheBlueMatt and jkczyz September 12, 2025 00:12

jkczyz reviewed Sep 12, 2025

View reviewed changes

		// FIXME: Either we bring back the `OUR_TX_SIGNATURES_READY` flag for this specific
		// case, or we somehow access the signing session to check it instead.

		#[cfg(debug_assertions)]
		let sent_or_received_tx_signatures = self

Splice channel state rework #4061

Are you sure you want to change the base?

Splice channel state rework #4061

Conversation

wpaulino commented Sep 5, 2025

Uh oh!

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

Uh oh!

Uh oh!

graphite-app bot Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Sep 8, 2025

Uh oh!

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

Uh oh!

Codecov Report

Uh oh!

graphite-app bot Sep 9, 2025

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Sep 11, 2025

Uh oh!

ldk-reviews-bot commented Sep 11, 2025

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

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!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkczyz left a comment

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 5, 2025 •

edited

Loading

codecov bot commented Sep 8, 2025 •

edited

Loading