Fix minor miscellaneous splicing issues #4060

wpaulino · 2025-09-05T22:50:24Z

This was pulled out of #4054 to ease review. It fixes an assortment of issues I ran into while writing the tests there.

ldk-reviews-bot · 2025-09-05T22:50:27Z

👋 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-reviews-bot · 2025-09-08T00:00:38Z

🔔 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-08T00:00:39Z

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

jkczyz · 2025-09-08T15:44:22Z

lightning/src/chain/channelmonitor.rs

 						}
+						removed_fulfilled_htlcs = true;


Could we just run the loop below at this point and return rather than needing this variable?

It's just a small optimization to not remove HTLCs that have already been removed since we have duplicate data across FundingScopes. The loop below does need to run for every FundingScope though.

Right, but that is already inside the closure, which is called on each FundingScope.

Oh, nevermind. Didn't see that removed_fulfilled_htlcs is used across all calls.

jkczyz · 2025-09-08T16:16:12Z

lightning/src/ln/channel.rs

+					{
+						Some(interactive_tx_constructor)
+					} else {
+						None


Is this also unreachable?

I think we actually don't want any unreachables since they can be triggered by a buggy/malicious counterparty.

jkczyz · 2025-09-08T16:31:18Z

lightning/src/ln/channel.rs

+			ChannelPhase::UnfundedOutboundV1(_) => unreachable!(),
+			ChannelPhase::UnfundedInboundV1(_) => unreachable!(),
+			ChannelPhase::UnfundedV2(pending_v2_channel) => {
+				pending_v2_channel.interactive_tx_constructor.take()


Can't recall if we eventually want to use FundingNegotiation here, too. Can wait, of course, but we may be able avoid these unreachables if we can take that at the call sites below.

We're not quite using that yet for dual funding so I'd rather delay it until we do.

lightning/src/ln/interactivetxs.rs

TheBlueMatt

Basically LGTM

TheBlueMatt · 2025-09-08T17:10:25Z

lightning/src/ln/channel.rs

@@ -1782,7 +1964,7 @@ where

 	pub fn funding_tx_constructed<L: Deref>(
 		&mut self, logger: &L,
-	) -> Result<msgs::CommitmentSigned, msgs::TxAbort>
+	) -> Result<msgs::CommitmentSigned, AbortReason>


Wanna make these methods non-pub now? Makes the logic more readable.

Done, I think it was just funding_tx_constructed and interactive_tx_constructor_mut?

lightning/src/ln/splicing_tests.rs

lightning/src/chain/channelmonitor.rs

Otherwise we'll hit an assert that we do not already have an alternative funding confirmation when reprocessing the transaction.

…cked The `ChannelMonitor` now tracks its own set of channel parameters, but in the event they change after a splice, we want to ensure they are updated accordingly at the `OnchainTxHandler` level as well in case the user downgrades after a locked splice has already occurred.

We only need to track the HTLC sources for the previous and current counterparty commitments.

This commit reworks all interactive transaction construction methods to mark the negotiation as failed upon a local/remote `TxAbort`, ensuring the `InteractiveTxConstructor` is consumed. Along the way, we refactor the handling of `tx_complete` such that we only have a single call into the `Channel` from the `ChannelManager`.

The splice shared input weight should always be composed of the base input weight (prevout & sequence), an empty `script_sig` weight, and the multisig channel-type specific witness weight.

Although a splice out doesn't include inputs to sign, users still need to call back with `funding_transaction_signed` to sign the shared splice input.

graphite-app · 2025-09-08T20:44:09Z

lightning/src/ln/splicing_tests.rs

 	let events = initiator_node.node.get_and_clear_pending_msg_events();
-	assert_eq!(events.len(), 2);
+	assert_eq!(events.len(), 1);
 	match events[0] {
-		MessageSendEvent::SendTxComplete { .. } => {},
-		_ => panic!("Unexpected event {:?}", events[0]),
-	}
-	match events[1] {
 		MessageSendEvent::SendTxAbort { .. } => {},
-		_ => panic!("Unexpected event {:?}", events[1]),
+		_ => panic!("Unexpected event {:?}", events[0]),
 	}


The test is using the wrong variable in the handle_tx_complete call. It captures the latest tx_complete message as _tx_complete_msg (with an underscore), but then passes the earlier tx_complete_msg from line 244 to the handler. This could lead to incorrect behavior since it's processing the wrong message. The variable names should be consistent, and the latest message should be used in the handler call.

Spotted by Diamond

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

This looks to predate the PR, but shouldn't affect behavior given tx_complete only contains a channel id.

Yeah this test is getting removed completely in #4054 anyway.

jkczyz · 2025-09-08T21:03:08Z

lightning/src/ln/splicing_tests.rs

 	let events = initiator_node.node.get_and_clear_pending_msg_events();
-	assert_eq!(events.len(), 2);
+	assert_eq!(events.len(), 1);
 	match events[0] {
-		MessageSendEvent::SendTxComplete { .. } => {},
-		_ => panic!("Unexpected event {:?}", events[0]),
-	}
-	match events[1] {
 		MessageSendEvent::SendTxAbort { .. } => {},
-		_ => panic!("Unexpected event {:?}", events[1]),
+		_ => panic!("Unexpected event {:?}", events[0]),
 	}


This looks to predate the PR, but shouldn't affect behavior given tx_complete only contains a channel id.

TheBlueMatt

Gonna land this but think we need to fix the dual-funding failure handling.

TheBlueMatt · 2025-09-09T18:48:28Z

lightning/src/ln/channel.rs

+			ChannelPhase::Undefined => unreachable!(),
+			ChannelPhase::UnfundedOutboundV1(_) | ChannelPhase::UnfundedInboundV1(_) => None,
+			ChannelPhase::UnfundedV2(pending_v2_channel) => {
+				pending_v2_channel.interactive_tx_constructor.take()


Can we really just blindly take this? Its set up in new for inbound channels, so we probably should be outright failing the channel here, not resetting the signing session?

Same applies further down.

Dual funding hasn't been updated to use the new interactive tx path, it shouldn't even have an interactive tx constructor in new yet without calling FundingNegotiationContext::into_interactive_tx_constructor.

wpaulino added this to the 0.2 milestone Sep 5, 2025

wpaulino requested review from TheBlueMatt and jkczyz September 5, 2025 22:50

wpaulino self-assigned this Sep 5, 2025

This was referenced Sep 5, 2025

Add basic end-to-end splice tests #4054

Open

Splice channel state rework #4061

Open

jkczyz reviewed Sep 8, 2025

View reviewed changes

TheBlueMatt reviewed Sep 8, 2025

View reviewed changes

wpaulino force-pushed the splice-misc-fixes branch 2 times, most recently from b1d97a1 to 9540ede Compare September 8, 2025 19:14

graphite-app bot reviewed Sep 8, 2025

View reviewed changes

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

lightning/src/chain/channelmonitor.rs Outdated Show resolved Hide resolved

wpaulino added 10 commits September 8, 2025 13:40

Don't process alternative funding confirmations duplicatively

3023e2f

Otherwise we'll hit an assert that we do not already have an alternative funding confirmation when reprocessing the transaction.

Prune HTLC sources from pending funding scopes

ea42df4

We only need to track the HTLC sources for the previous and current counterparty commitments.

Fix incorrect weight estimation for splice shared input

33079be

The splice shared input weight should always be composed of the base input weight (prevout & sequence), an empty `script_sig` weight, and the multisig channel-type specific witness weight.

Detect splice out as local contribution

4cc8d5a

Although a splice out doesn't include inputs to sign, users still need to call back with `funding_transaction_signed` to sign the shared splice input.

Remove stale TODO for quiescence check on incoming splice_init

5c6b637

Remove splicing rust cfg flag

bb0f5ab

Remove useless use of format! throughout splicing errors

1bda3eb

Remove let binding for unit values in splice test

1dc190d

wpaulino force-pushed the splice-misc-fixes branch from 9540ede to 1dc190d Compare September 8, 2025 20:41

wpaulino requested review from TheBlueMatt and jkczyz September 8, 2025 20:42

graphite-app bot reviewed Sep 8, 2025

View reviewed changes

jkczyz approved these changes Sep 8, 2025

View reviewed changes

TheBlueMatt approved these changes Sep 9, 2025

View reviewed changes

TheBlueMatt merged commit 3324799 into lightningdevkit:main Sep 9, 2025
22 of 23 checks passed

wpaulino deleted the splice-misc-fixes branch September 9, 2025 19:57

Fix minor miscellaneous splicing issues #4060

Fix minor miscellaneous splicing issues #4060

Uh oh!

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!

ldk-reviews-bot commented Sep 8, 2025

Uh oh!

ldk-reviews-bot commented Sep 8, 2025

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TheBlueMatt 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!

Uh oh!

Uh oh!

graphite-app bot Sep 8, 2025

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!

TheBlueMatt 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!

Uh oh!

Uh oh!

ldk-reviews-bot commented Sep 5, 2025 •

edited

Loading