Add splice-out support #3979

jkczyz · 2025-07-31T16:11:16Z

Splice-in support was added in #3736. This PR expands ChannelManager::splice_channel to support splice-out (i.e., removing funds from a channel). This is accomplished by adding a FundingTxContributions enum to cover both use cases.

Depends on #3736.

ldk-reviews-bot · 2025-07-31T16:11:18Z

👋 Thanks for assigning @wpaulino 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-07-31T16:27:41Z

Codecov Report

❌ Patch coverage is 70.51282% with 46 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.83%. Comparing base (6d47f0a) to head (9c2f266).
⚠️ Report is 31 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	29.41%	15 Missing and 9 partials ⚠️
lightning/src/ln/channelmanager.rs	52.77%	16 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	84.61%	2 Missing and 2 partials ⚠️
lightning/src/ln/interactivetxs.rs	97.95%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3979      +/-   ##
==========================================
+ Coverage   88.74%   88.83%   +0.09%     
==========================================
  Files         173      175       +2     
  Lines      124899   127732    +2833     
  Branches   124899   127732    +2833     
==========================================
+ Hits       110841   113477    +2636     
- Misses      11631    11686      +55     
- Partials     2427     2569     +142

Flag	Coverage Δ
fuzzing	`21.85% <2.70%> (?)`
tests	`88.67% <69.23%> (-0.08%)`	⬇️

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.

ldk-reviews-bot · 2025-08-04T00:01:04Z

🔔 1st Reminder

Hey @wpaulino! 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.

lightning/src/ln/channel.rs

wpaulino · 2025-08-04T19:19:38Z

lightning/src/ln/channel.rs

@@ -6079,7 +6081,7 @@ pub enum FundingTxContributions {
 	InputsOnly {
 		/// The inputs used to meet the contributed amount. Any excess amount will be sent to a
 		/// change output.
-		inputs: Vec<(TxIn, Transaction)>,
+		inputs: Vec<(TxIn, Transaction, Weight)>,


Let's make this a struct now so we can properly document each field. The weight here should be the witness_weight for the input to be spent. We may even be able to reuse bump_transaction::Utxo.

We may even be able to reuse bump_transaction::Utxo.

Hmm... that doesn't have a TxIn. We also need the full previous transaction in InteractiveTxConstructor to use as prevtx in tx_add_input.

We would just need to track TxIn::sequence and prevtx separately if we choose to go with it

lightning/src/ln/interactivetxs.rs

lightning/src/ln/channel.rs

wpaulino · 2025-08-04T19:26:57Z

lightning/src/ln/channel.rs

+				our_funding_contribution_satoshis,
+			);
+			// FIXME: Should we check value_to_self instead? Do HTLCs need to be accounted for?
+			// FIXME: Check that we can pay for the outputs from the channel value?


We probably don't even need our_funding_contribution for a splice out, we can just assume it from adding all the output values

Ah, good point. For paying for the outputs, seems we should actually use check_v2_funding_inputs_sufficient for both splice-in and splice-out and account for outputs?

Ah, actually that only looks at the input from the previous funding transaction for weight, not amount.

Re-wrote this to ensure fees for the funding outputs are accounted for. One thing of note is that our_funding_contribution for a splice-out needs to be adjusted by the fees to be paid (i.e., fees need to be subtracted from the negative our_funding_contribution to increase the amount being removed from the channel).

Also, a bit of an oversight, but we don't yet support accepting a splice-out. Technically, it could contain both inputs and outputs even if the net amount is negative. But I think we shouldn't care as long as we check everything is sane upon exchanging tx_complete.

lightning/src/ln/channel.rs

ldk-reviews-bot · 2025-08-04T19:28:52Z

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

ldk-reviews-bot · 2025-08-11T00:00:21Z

🔔 1st Reminder

Hey @wpaulino! 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.

Splice contributions should never exceed the total bitcoin supply. This check prevents a potential overflow when converting the contribution from sats to msats. The commit additionally begins to store the contribution using SignedAmount.

jkczyz · 2025-08-11T16:41:48Z

Rebased to resolve merge conflicts.

jkczyz · 2025-08-11T22:22:26Z

Squashed as requested.

wpaulino · 2025-08-12T16:40:18Z

lightning/src/ln/channel.rs

@@ -10724,21 +10735,38 @@ where
 			)));
 		}

-		if their_funding_contribution_satoshis.saturating_add(our_funding_contribution_satoshis) < 0
-		{
+		if our_funding_contribution > SignedAmount::MAX_MONEY {


Nit: this check doesn't really belong here, ideally it's done when the user tells us they're interested in contributing to an incoming splice

Right, I suppose we'd never pass in our_funding_contribution when handling splice_ack. Rather, we'd surface an event to allow users to contribute.

Added a TODO to move the check once user-provided contributions are supported for counterparty-initiated splices.

wpaulino · 2025-08-12T16:51:31Z

lightning/src/ln/channelmanager.rs

+/// An input to contribute to a channel's funding transaction either when using the v2 channel
+/// establishment protocol or when splicing.
+#[derive(Clone)]
+pub struct FundingTxInput {


I still think reusing Utxo internally would be a good fit here if we can make it happen.

We could then have helpers like FundingTxInput::new_p2wpkh(tx, vout, sequence) and others to make it simpler for the user.

I still think reusing Utxo internally would be a good fit here if we can make it happen.

Are you saying something like the following?

pub struct FundingTxInput { utxo: Utxo, sequence: Sequence, prevtx: Transaction, }

We could then have helpers like FundingTxInput::new_p2wpkh(tx, vout, sequence) and others to make it simpler for the user.

If this re-used Utxo::new_p2wpkh, won't the weight in FundingTxInput::utxo be wrong? It includes the weight of TxIn::script_sig, not just the witness.

Hmm... maybe estimate_v2_funding_transaction_fee isn't correct. It isn't including the script_sig in the calculation, AFAICT.

Oh, nevermind. Forgot that script_sig is empty in segwit transactions.

As discussed offline, added FundingTxInput with dedicated constructors where some requiring a witness script.

wpaulino · 2025-08-12T16:51:55Z

lightning/src/ln/channelmanager.rs

+#[derive(Clone)]
+pub struct FundingTxInput {
+	/// An input for the funding transaction used to cover the channel contributions.
+	pub txin: TxIn,


We really just need the previous_output and sequence, not the full TxIn. Would also be nice to track the TxOut separately so that we can just check it once during initialization and never have to worry about it again.

Ah, so the TxOut created in Utxo would be checked against the provided prevtx on initialization?

Ended up having the FundingTxInput constructors create Utxo inline rather than relying on its constructors in order to properly set satisfaction_weight.

lightning/src/ln/channelmanager.rs

wpaulino · 2025-08-12T17:05:38Z

lightning/src/ln/channel.rs

+			funding_feerate.to_sat_per_kwu() as u32,
+		));
+
+		if channel_balance > contribution_amount.unsigned_abs() + estimated_fee {


This isn't enough, we need to make sure the balance is still above the reserve and has enough to pay for fees on the commitment transaction if they're the channel initiator

Right, the reserve check will be at the call site as a separate check. I hadn't considered the fees for the commitment transaction. For the splice-in case, is it assumed it is sufficient because it was sufficient with the previous funding contributions?

For the splice-in case, is it assumed it is sufficient because it was sufficient with the previous funding contributions?

Most likely yeah, but it's better to be safe than sorry. We already need to always check it for the counterparty and for our splice-outs, so might as well always do it for splice-ins.

Leaving this for @tankyleo.

lightning/src/ln/channel.rs

…text Once the counterparty supplies their funding contribution, there is no longer a need to store it in FundingNegotiationContext as it will have already been used to create a FundingScope.

TransactionU16LenLimited was used to limit Transaction serialization size to u16::MAX. This was because messages can not be longer than u16::MAX bytes when serialized for the transport layer. However, this limit doesn't take into account other fields in a message containing a Transaction, including the length of the transaction itself. Remove TransactionU16LenLimited and instead check any user supplied transactions in the context of the enclosing message (e.g. TxAddInput).

ChannelManager::splice_channel takes witness weights with the funding inputs. Storing these in FundingNegotiationContext allows us to use them when calculating the change output and include them in a common struct used for initiating a splice-in. In preparation for having ChannelManager::splice_channel take FundingTxContributions, add a weight to the FundingTxContributions::InputsOnly, which supports the splice-in use case.

The funding inputs used for splicing and v2 channel establishment are passed as a tuple of txin, prevtx, and witness weight. Add a struct so that the items included can be better documented.

ChannelManager::splice_channel takes individual parameters to support splice-in. Change these to an enum such that it can be used for splice-out as well.

Update SpliceContribution with a variant used to support splice-out (i.e., removing funds from a channel). The TxOut values must not exceed the users channel balance after accounting for fees and the reserve requirement.

When a counterparty sends splice_init with a negative contribution, they are requesting to remove funds from a channel. Remove conditions guarding against this and check that they have enough channel balance to cover the removed funds.

jkczyz requested a review from wpaulino July 31, 2025 16:11

jkczyz marked this pull request as draft July 31, 2025 16:11

jkczyz added this to Weekly Goals Jul 31, 2025

jkczyz self-assigned this Jul 31, 2025

jkczyz mentioned this pull request Jul 31, 2025

Dual-funded channels and Splicing Project Tracking #1621

Open

7 tasks

jkczyz force-pushed the 2025-07-splice-out branch 3 times, most recently from 2d39059 to 381fba6 Compare August 1, 2025 00:23

jkczyz marked this pull request as ready for review August 1, 2025 00:23

wpaulino reviewed Aug 4, 2025

View reviewed changes

jkczyz force-pushed the 2025-07-splice-out branch 2 times, most recently from 396948e to 59fbd7e Compare August 7, 2025 23:38

jkczyz requested a review from wpaulino August 8, 2025 13:42

jkczyz force-pushed the 2025-07-splice-out branch from fde2f61 to f12c993 Compare August 11, 2025 16:39

jkczyz force-pushed the 2025-07-splice-out branch from f12c993 to 806220e Compare August 11, 2025 22:22

wpaulino reviewed Aug 12, 2025

View reviewed changes

jkczyz added 6 commits August 13, 2025 18:00

f - add TODO

186068d

Remove their_funding_contribution_satoshis from FundingNegotiationCon…

e42bed3

…text Once the counterparty supplies their funding contribution, there is no longer a need to store it in FundingNegotiationContext as it will have already been used to create a FundingScope.

Replace funding input tuple with struct

1496e2d

The funding inputs used for splicing and v2 channel establishment are passed as a tuple of txin, prevtx, and witness weight. Add a struct so that the items included can be better documented.

f - reuse Utxo

88c8c3b

jkczyz added 9 commits August 13, 2025 18:39

f - add more constructors

9847c9e

f - fix doc link

fb79c61

Use a SpliceContribution enum for passing splice-in params

d716168

ChannelManager::splice_channel takes individual parameters to support splice-in. Change these to an enum such that it can be used for splice-out as well.

f - doc fixes

80a6c26

Add splice-out support

fc8e444

Update SpliceContribution with a variant used to support splice-out (i.e., removing funds from a channel). The TxOut values must not exceed the users channel balance after accounting for fees and the reserve requirement.

f - fix error message

4e92e0a

f - drop unnecessary check

af94f0e

f - rustfmt

ed672d9

Support accepting splice-out

9c2f266

When a counterparty sends splice_init with a negative contribution, they are requesting to remove funds from a channel. Remove conditions guarding against this and check that they have enough channel balance to cover the removed funds.

jkczyz force-pushed the 2025-07-splice-out branch from 806220e to 9c2f266 Compare August 13, 2025 23:58

jkczyz requested a review from wpaulino August 13, 2025 23:58

Add splice-out support #3979

Are you sure you want to change the base?

Add splice-out support #3979

Conversation

jkczyz commented Jul 31, 2025

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Codecov Report

Uh oh!

ldk-reviews-bot commented Aug 4, 2025

Uh oh!

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!

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!

Uh oh!

ldk-reviews-bot commented Aug 4, 2025

Uh oh!

ldk-reviews-bot commented Aug 11, 2025

Uh oh!

jkczyz commented Aug 11, 2025

Uh oh!

jkczyz commented Aug 11, 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Jul 31, 2025 •

edited

Loading

codecov bot commented Jul 31, 2025 •

edited

Loading