Validate funding contributions reserves in `splice_init` and `splice_ack` handling by tankyleo · Pull Request #4011 · lightningdevkit/rust-lightning

tankyleo · 2025-08-14T01:21:41Z

 Check v2 reserves after `funding_contribution_satoshis` is applied
We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.
From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```
and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```
Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.
We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

ldk-reviews-bot · 2025-08-14T01:21:43Z

👋 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-08-14T01:31:40Z

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (bf87832) to head (85a02ca).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/tx_builder.rs	38.09%	13 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4011 +/- ##
==========================================
+ Coverage 88.76% 88.77% +0.01% 
==========================================
Files 176 176 Lines 129345 129357 +12 Branches 129345 129357 +12 ==========================================
+ Hits 114812 114836 +24 + Misses 11925 11921 -4 + Partials 2608 2600 -8

Flag	Coverage Δ
fuzzing	`22.00% <23.80%> (-0.01%)`	⬇️
tests	`88.60% <38.09%> (+0.01%)`	⬆️

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-16T01:25:45Z

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

ldk-reviews-bot · 2025-08-18T01:26:28Z

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

tankyleo · 2025-08-19T18:02:47Z

On hold until splice-out PR gets in.

ldk-reviews-bot · 2025-08-20T01:27:13Z

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

ldk-reviews-bot · 2025-08-26T23:35:08Z

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

tankyleo · 2025-08-27T02:30:54Z

Rebase on merge-base (diff):

Always run the reserve check, not just when the funding contribution is negative.
Make sure that the funder of the channel can pay for an additional nondust HTLC after the contributions are applied.
Emit WarnAndDisconnect if the balance is exhausted.
Style improvements.

tankyleo · 2025-08-27T05:54:02Z

Amend: (diff)

Run the reserve check anytime the funding contribution is not zero.

tankyleo · 2025-08-27T16:27:00Z

Rebasing now to fix conflict...

TheBlueMatt · 2025-09-01T20:24:50Z

- let their_channel_balance = Amount::from_sat(self.funding.get_value_satoshis())
- - Amount::from_sat(self.funding.get_value_to_self_msat() / 1000);
- let post_channel_balance = AddSigned::checked_add_signed(
+ let adjusted_funding_contribution = if let Some((contribution, is_initiator, feerate)) =


Are we sure this is right in the splice_ack case? In the splice_channel (initiate outbound splice) case, we pass the total contribution ignoring fees, which then mandates that we subtract the fee here. But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here. IMO we should pull this back out to the splice_channel method and keep this method strictly a symmetrical splice validation function that doesn't have any sender/recipient-specific logic at all. Once we make get_next_{local,remote}_commitment_stats fallible it'll just be a matter of calling that and checking the reserve, basically.

Will look into it thank you
But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here.
When we receive splice_ack, we set this triple to None, and we don't subtract the fee here ?
I'll revisit this part in any case.

Ah, sorry, duh, all the more confusing code tho :)

TheBlueMatt

Okay, thanks for rewriting this four times 😅. Feel free to squash (looks like the latest fixup needs to get moved back a bit), I think this LGTM. cc @wpaulino

TheBlueMatt · 2025-09-02T17:47:06Z

Also sadly needs rebase.

tankyleo · 2025-09-02T22:06:41Z

First rebase: no diff, squash fixups, reorganize commits.

As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

`NextCommitmentStats` provides the commitment transaction fee as a separate value to assist with applying a multiplier on it in `can_accept_incoming_htlc`. Nonetheless in most cases, we want the balances to include the commitment transaction fee, so here we add a helper that gives us these balances. Also make the style of `tx_builder::subtract_addl_outputs` consistent with `get_balances_including_fee`.

The reserve we should maintain on our own transaction should be greater than our own dust limit.

We check this when validating `splice_init`, `splice_ack` messages, and also when validating user-specified contributions. From BOLT 2: ``` - If `funding_contribution_satoshis` is negative and its absolute value is greater than the sending node's current channel balance: - MUST send a `warning` and close the connection or send an `error` and fail the channel. ``` and further down: ``` If a side does not meet the reserve requirements, that's OK: but if they take funds out of the channel, they must ensure that they do meet them. If your peer adds a massive amount to the channel, then you only have to add more reserve if you want to contribute to the splice (and you can use `tx_remove_output` and/or `tx_remove_input` part-way through if this happens). ``` Therefore, we check the v2 reserve anytime `funding_contribution_satoshis` is not equal to zero. We allow parties to draw from their previous reserve, as long as they satisfy their v2 reserve.

tankyleo · 2025-09-02T22:45:06Z

Second rebase: move base commit to bf87832 , use inline format arguments in some places.

TheBlueMatt

One question, otherwise LGTM

TheBlueMatt · 2025-09-03T14:31:50Z

 // New reserve values are based on the new channel value and are v2-specific
- let counterparty_selected_channel_reserve_satoshis = Some(get_v2_channel_reserve_satoshis(
+ let counterparty_selected_channel_reserve_satoshis =
+ Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));


Wait, I thin this is wrong (and also maybe reserves should be higher than both dust limits?). Not sure what the spec says, but the point of the reserve is to have something that we can be punished for when broadcasting our own stale transaction. Thus, the reserve we keep should really be higher than our own dust limit (which applies to our local commitment transactions that we can broadcast) so that if we broadcast a stale state we can be punished.

Isn't that what we have here ?
MIN_CHAN_DUST_LIMIT_SATOSHIS: our own dust limit
counterparty_selected_channel_reserve_satoshis: we must keep at least these many sats "punishable" on our broadcastable transaction.

tankyleo · 2025-08-14T01:21:41Z

 Check v2 reserves after `funding_contribution_satoshis` is applied
We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.
From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```
and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```
Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.
We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

ldk-reviews-bot · 2025-08-14T01:21:43Z

👋 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-08-14T01:31:40Z

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (bf87832) to head (85a02ca).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/tx_builder.rs	38.09%	13 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4011 +/- ##
==========================================
+ Coverage 88.76% 88.77% +0.01% 
==========================================
Files 176 176 Lines 129345 129357 +12 Branches 129345 129357 +12 ==========================================
+ Hits 114812 114836 +24 + Misses 11925 11921 -4 + Partials 2608 2600 -8

Flag	Coverage Δ
fuzzing	`22.00% <23.80%> (-0.01%)`	⬇️
tests	`88.60% <38.09%> (+0.01%)`	⬆️

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-16T01:25:45Z

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

ldk-reviews-bot · 2025-08-18T01:26:28Z

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

tankyleo · 2025-08-19T18:02:47Z

On hold until splice-out PR gets in.

ldk-reviews-bot · 2025-08-20T01:27:13Z

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

ldk-reviews-bot · 2025-08-26T23:35:08Z

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

tankyleo · 2025-08-27T02:30:54Z

Rebase on merge-base (diff):

Always run the reserve check, not just when the funding contribution is negative.
Make sure that the funder of the channel can pay for an additional nondust HTLC after the contributions are applied.
Emit WarnAndDisconnect if the balance is exhausted.
Style improvements.

tankyleo · 2025-08-27T05:54:02Z

Amend: (diff)

Run the reserve check anytime the funding contribution is not zero.

tankyleo · 2025-08-27T16:27:00Z

Rebasing now to fix conflict...

TheBlueMatt · 2025-09-01T20:24:50Z

- let their_channel_balance = Amount::from_sat(self.funding.get_value_satoshis())
- - Amount::from_sat(self.funding.get_value_to_self_msat() / 1000);
- let post_channel_balance = AddSigned::checked_add_signed(
+ let adjusted_funding_contribution = if let Some((contribution, is_initiator, feerate)) =


Are we sure this is right in the splice_ack case? In the splice_channel (initiate outbound splice) case, we pass the total contribution ignoring fees, which then mandates that we subtract the fee here. But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here. IMO we should pull this back out to the splice_channel method and keep this method strictly a symmetrical splice validation function that doesn't have any sender/recipient-specific logic at all. Once we make get_next_{local,remote}_commitment_stats fallible it'll just be a matter of calling that and checking the reserve, basically.

Will look into it thank you
But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here.
When we receive splice_ack, we set this triple to None, and we don't subtract the fee here ?
I'll revisit this part in any case.

Ah, sorry, duh, all the more confusing code tho :)

TheBlueMatt

Okay, thanks for rewriting this four times 😅. Feel free to squash (looks like the latest fixup needs to get moved back a bit), I think this LGTM. cc @wpaulino

TheBlueMatt · 2025-09-02T17:47:06Z

Also sadly needs rebase.

tankyleo · 2025-09-02T22:06:41Z

First rebase: no diff, squash fixups, reorganize commits.

As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

`NextCommitmentStats` provides the commitment transaction fee as a separate value to assist with applying a multiplier on it in `can_accept_incoming_htlc`. Nonetheless in most cases, we want the balances to include the commitment transaction fee, so here we add a helper that gives us these balances. Also make the style of `tx_builder::subtract_addl_outputs` consistent with `get_balances_including_fee`.

The reserve we should maintain on our own transaction should be greater than our own dust limit.

We check this when validating `splice_init`, `splice_ack` messages, and also when validating user-specified contributions. From BOLT 2: ``` - If `funding_contribution_satoshis` is negative and its absolute value is greater than the sending node's current channel balance: - MUST send a `warning` and close the connection or send an `error` and fail the channel. ``` and further down: ``` If a side does not meet the reserve requirements, that's OK: but if they take funds out of the channel, they must ensure that they do meet them. If your peer adds a massive amount to the channel, then you only have to add more reserve if you want to contribute to the splice (and you can use `tx_remove_output` and/or `tx_remove_input` part-way through if this happens). ``` Therefore, we check the v2 reserve anytime `funding_contribution_satoshis` is not equal to zero. We allow parties to draw from their previous reserve, as long as they satisfy their v2 reserve.

tankyleo · 2025-09-02T22:45:06Z

Second rebase: move base commit to bf87832 , use inline format arguments in some places.

TheBlueMatt

One question, otherwise LGTM

TheBlueMatt · 2025-09-03T14:31:50Z

 // New reserve values are based on the new channel value and are v2-specific
- let counterparty_selected_channel_reserve_satoshis = Some(get_v2_channel_reserve_satoshis(
+ let counterparty_selected_channel_reserve_satoshis =
+ Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));


Wait, I thin this is wrong (and also maybe reserves should be higher than both dust limits?). Not sure what the spec says, but the point of the reserve is to have something that we can be punished for when broadcasting our own stale transaction. Thus, the reserve we keep should really be higher than our own dust limit (which applies to our local commitment transactions that we can broadcast) so that if we broadcast a stale state we can be punished.

Isn't that what we have here ?
MIN_CHAN_DUST_LIMIT_SATOSHIS: our own dust limit
counterparty_selected_channel_reserve_satoshis: we must keep at least these many sats "punishable" on our broadcastable transaction.

tankyleo · 2025-08-14T01:21:41Z

 Check v2 reserves after `funding_contribution_satoshis` is applied
We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.
From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```
and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```
Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.
We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

ldk-reviews-bot · 2025-08-14T01:21:43Z

👋 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-08-14T01:31:40Z

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (bf87832) to head (85a02ca).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/tx_builder.rs	38.09%	13 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4011 +/- ##
==========================================
+ Coverage 88.76% 88.77% +0.01% 
==========================================
Files 176 176 Lines 129345 129357 +12 Branches 129345 129357 +12 ==========================================
+ Hits 114812 114836 +24 + Misses 11925 11921 -4 + Partials 2608 2600 -8

Flag	Coverage Δ
fuzzing	`22.00% <23.80%> (-0.01%)`	⬇️
tests	`88.60% <38.09%> (+0.01%)`	⬆️

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-16T01:25:45Z

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

ldk-reviews-bot · 2025-08-18T01:26:28Z

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

tankyleo · 2025-08-19T18:02:47Z

On hold until splice-out PR gets in.

ldk-reviews-bot · 2025-08-20T01:27:13Z

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

ldk-reviews-bot · 2025-08-26T23:35:08Z

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

tankyleo · 2025-08-27T02:30:54Z

Rebase on merge-base (diff):

Always run the reserve check, not just when the funding contribution is negative.
Make sure that the funder of the channel can pay for an additional nondust HTLC after the contributions are applied.
Emit WarnAndDisconnect if the balance is exhausted.
Style improvements.

tankyleo · 2025-08-27T05:54:02Z

Amend: (diff)

Run the reserve check anytime the funding contribution is not zero.

tankyleo · 2025-08-27T16:27:00Z

Rebasing now to fix conflict...

TheBlueMatt · 2025-09-01T20:24:50Z

- let their_channel_balance = Amount::from_sat(self.funding.get_value_satoshis())
- - Amount::from_sat(self.funding.get_value_to_self_msat() / 1000);
- let post_channel_balance = AddSigned::checked_add_signed(
+ let adjusted_funding_contribution = if let Some((contribution, is_initiator, feerate)) =


Are we sure this is right in the splice_ack case? In the splice_channel (initiate outbound splice) case, we pass the total contribution ignoring fees, which then mandates that we subtract the fee here. But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here. IMO we should pull this back out to the splice_channel method and keep this method strictly a symmetrical splice validation function that doesn't have any sender/recipient-specific logic at all. Once we make get_next_{local,remote}_commitment_stats fallible it'll just be a matter of calling that and checking the reserve, basically.

Will look into it thank you
But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here.
When we receive splice_ack, we set this triple to None, and we don't subtract the fee here ?
I'll revisit this part in any case.

Ah, sorry, duh, all the more confusing code tho :)

TheBlueMatt

Okay, thanks for rewriting this four times 😅. Feel free to squash (looks like the latest fixup needs to get moved back a bit), I think this LGTM. cc @wpaulino

TheBlueMatt · 2025-09-02T17:47:06Z

Also sadly needs rebase.

tankyleo · 2025-09-02T22:06:41Z

First rebase: no diff, squash fixups, reorganize commits.

As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

`NextCommitmentStats` provides the commitment transaction fee as a separate value to assist with applying a multiplier on it in `can_accept_incoming_htlc`. Nonetheless in most cases, we want the balances to include the commitment transaction fee, so here we add a helper that gives us these balances. Also make the style of `tx_builder::subtract_addl_outputs` consistent with `get_balances_including_fee`.

The reserve we should maintain on our own transaction should be greater than our own dust limit.

We check this when validating `splice_init`, `splice_ack` messages, and also when validating user-specified contributions. From BOLT 2: ``` - If `funding_contribution_satoshis` is negative and its absolute value is greater than the sending node's current channel balance: - MUST send a `warning` and close the connection or send an `error` and fail the channel. ``` and further down: ``` If a side does not meet the reserve requirements, that's OK: but if they take funds out of the channel, they must ensure that they do meet them. If your peer adds a massive amount to the channel, then you only have to add more reserve if you want to contribute to the splice (and you can use `tx_remove_output` and/or `tx_remove_input` part-way through if this happens). ``` Therefore, we check the v2 reserve anytime `funding_contribution_satoshis` is not equal to zero. We allow parties to draw from their previous reserve, as long as they satisfy their v2 reserve.

tankyleo · 2025-09-02T22:45:06Z

Second rebase: move base commit to bf87832 , use inline format arguments in some places.

TheBlueMatt

One question, otherwise LGTM

TheBlueMatt · 2025-09-03T14:31:50Z

 // New reserve values are based on the new channel value and are v2-specific
- let counterparty_selected_channel_reserve_satoshis = Some(get_v2_channel_reserve_satoshis(
+ let counterparty_selected_channel_reserve_satoshis =
+ Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));


Wait, I thin this is wrong (and also maybe reserves should be higher than both dust limits?). Not sure what the spec says, but the point of the reserve is to have something that we can be punished for when broadcasting our own stale transaction. Thus, the reserve we keep should really be higher than our own dust limit (which applies to our local commitment transactions that we can broadcast) so that if we broadcast a stale state we can be punished.

Isn't that what we have here ?
MIN_CHAN_DUST_LIMIT_SATOSHIS: our own dust limit
counterparty_selected_channel_reserve_satoshis: we must keep at least these many sats "punishable" on our broadcastable transaction.

tankyleo · 2025-08-14T01:21:41Z

 Check v2 reserves after `funding_contribution_satoshis` is applied
We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.
From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```
and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```
Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.
We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

ldk-reviews-bot · 2025-08-14T01:21:43Z

👋 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-08-14T01:31:40Z

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (bf87832) to head (85a02ca).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/tx_builder.rs	38.09%	13 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4011 +/- ##
==========================================
+ Coverage 88.76% 88.77% +0.01% 
==========================================
Files 176 176 Lines 129345 129357 +12 Branches 129345 129357 +12 ==========================================
+ Hits 114812 114836 +24 + Misses 11925 11921 -4 + Partials 2608 2600 -8

Flag	Coverage Δ
fuzzing	`22.00% <23.80%> (-0.01%)`	⬇️
tests	`88.60% <38.09%> (+0.01%)`	⬆️

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-16T01:25:45Z

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

ldk-reviews-bot · 2025-08-18T01:26:28Z

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

tankyleo · 2025-08-19T18:02:47Z

On hold until splice-out PR gets in.

ldk-reviews-bot · 2025-08-20T01:27:13Z

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

ldk-reviews-bot · 2025-08-26T23:35:08Z

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

tankyleo · 2025-08-27T02:30:54Z

Rebase on merge-base (diff):

Always run the reserve check, not just when the funding contribution is negative.
Make sure that the funder of the channel can pay for an additional nondust HTLC after the contributions are applied.
Emit WarnAndDisconnect if the balance is exhausted.
Style improvements.

tankyleo · 2025-08-27T05:54:02Z

Amend: (diff)

Run the reserve check anytime the funding contribution is not zero.

tankyleo · 2025-08-27T16:27:00Z

Rebasing now to fix conflict...

TheBlueMatt · 2025-09-01T20:24:50Z

- let their_channel_balance = Amount::from_sat(self.funding.get_value_satoshis())
- - Amount::from_sat(self.funding.get_value_to_self_msat() / 1000);
- let post_channel_balance = AddSigned::checked_add_signed(
+ let adjusted_funding_contribution = if let Some((contribution, is_initiator, feerate)) =


Are we sure this is right in the splice_ack case? In the splice_channel (initiate outbound splice) case, we pass the total contribution ignoring fees, which then mandates that we subtract the fee here. But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here. IMO we should pull this back out to the splice_channel method and keep this method strictly a symmetrical splice validation function that doesn't have any sender/recipient-specific logic at all. Once we make get_next_{local,remote}_commitment_stats fallible it'll just be a matter of calling that and checking the reserve, basically.

Will look into it thank you
But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here.
When we receive splice_ack, we set this triple to None, and we don't subtract the fee here ?
I'll revisit this part in any case.

Ah, sorry, duh, all the more confusing code tho :)

TheBlueMatt

Okay, thanks for rewriting this four times 😅. Feel free to squash (looks like the latest fixup needs to get moved back a bit), I think this LGTM. cc @wpaulino

TheBlueMatt · 2025-09-02T17:47:06Z

Also sadly needs rebase.

tankyleo · 2025-09-02T22:06:41Z

First rebase: no diff, squash fixups, reorganize commits.

As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

`NextCommitmentStats` provides the commitment transaction fee as a separate value to assist with applying a multiplier on it in `can_accept_incoming_htlc`. Nonetheless in most cases, we want the balances to include the commitment transaction fee, so here we add a helper that gives us these balances. Also make the style of `tx_builder::subtract_addl_outputs` consistent with `get_balances_including_fee`.

The reserve we should maintain on our own transaction should be greater than our own dust limit.

We check this when validating `splice_init`, `splice_ack` messages, and also when validating user-specified contributions. From BOLT 2: ``` - If `funding_contribution_satoshis` is negative and its absolute value is greater than the sending node's current channel balance: - MUST send a `warning` and close the connection or send an `error` and fail the channel. ``` and further down: ``` If a side does not meet the reserve requirements, that's OK: but if they take funds out of the channel, they must ensure that they do meet them. If your peer adds a massive amount to the channel, then you only have to add more reserve if you want to contribute to the splice (and you can use `tx_remove_output` and/or `tx_remove_input` part-way through if this happens). ``` Therefore, we check the v2 reserve anytime `funding_contribution_satoshis` is not equal to zero. We allow parties to draw from their previous reserve, as long as they satisfy their v2 reserve.

tankyleo · 2025-09-02T22:45:06Z

Second rebase: move base commit to bf87832 , use inline format arguments in some places.

TheBlueMatt

One question, otherwise LGTM

TheBlueMatt · 2025-09-03T14:31:50Z

 // New reserve values are based on the new channel value and are v2-specific
- let counterparty_selected_channel_reserve_satoshis = Some(get_v2_channel_reserve_satoshis(
+ let counterparty_selected_channel_reserve_satoshis =
+ Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));


Wait, I thin this is wrong (and also maybe reserves should be higher than both dust limits?). Not sure what the spec says, but the point of the reserve is to have something that we can be punished for when broadcasting our own stale transaction. Thus, the reserve we keep should really be higher than our own dust limit (which applies to our local commitment transactions that we can broadcast) so that if we broadcast a stale state we can be punished.

Isn't that what we have here ?
MIN_CHAN_DUST_LIMIT_SATOSHIS: our own dust limit
counterparty_selected_channel_reserve_satoshis: we must keep at least these many sats "punishable" on our broadcastable transaction.

tankyleo · 2025-08-14T01:21:41Z

 Check v2 reserves after `funding_contribution_satoshis` is applied
We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.
From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```
and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```
Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.
We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

ldk-reviews-bot · 2025-08-14T01:21:43Z

👋 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-08-14T01:31:40Z

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (bf87832) to head (85a02ca).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/tx_builder.rs	38.09%	13 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4011 +/- ##
==========================================
+ Coverage 88.76% 88.77% +0.01% 
==========================================
Files 176 176 Lines 129345 129357 +12 Branches 129345 129357 +12 ==========================================
+ Hits 114812 114836 +24 + Misses 11925 11921 -4 + Partials 2608 2600 -8

Flag	Coverage Δ
fuzzing	`22.00% <23.80%> (-0.01%)`	⬇️
tests	`88.60% <38.09%> (+0.01%)`	⬆️

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-16T01:25:45Z

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

ldk-reviews-bot · 2025-08-18T01:26:28Z

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

tankyleo · 2025-08-19T18:02:47Z

On hold until splice-out PR gets in.

ldk-reviews-bot · 2025-08-20T01:27:13Z

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

ldk-reviews-bot · 2025-08-26T23:35:08Z

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

tankyleo · 2025-08-27T02:30:54Z

Rebase on merge-base (diff):

Always run the reserve check, not just when the funding contribution is negative.
Make sure that the funder of the channel can pay for an additional nondust HTLC after the contributions are applied.
Emit WarnAndDisconnect if the balance is exhausted.
Style improvements.

tankyleo · 2025-08-27T05:54:02Z

Amend: (diff)

Run the reserve check anytime the funding contribution is not zero.

tankyleo · 2025-08-27T16:27:00Z

Rebasing now to fix conflict...

TheBlueMatt · 2025-09-01T20:24:50Z

- let their_channel_balance = Amount::from_sat(self.funding.get_value_satoshis())
- - Amount::from_sat(self.funding.get_value_to_self_msat() / 1000);
- let post_channel_balance = AddSigned::checked_add_signed(
+ let adjusted_funding_contribution = if let Some((contribution, is_initiator, feerate)) =


Are we sure this is right in the splice_ack case? In the splice_channel (initiate outbound splice) case, we pass the total contribution ignoring fees, which then mandates that we subtract the fee here. But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here. IMO we should pull this back out to the splice_channel method and keep this method strictly a symmetrical splice validation function that doesn't have any sender/recipient-specific logic at all. Once we make get_next_{local,remote}_commitment_stats fallible it'll just be a matter of calling that and checking the reserve, basically.

Will look into it thank you
But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here.
When we receive splice_ack, we set this triple to None, and we don't subtract the fee here ?
I'll revisit this part in any case.

Ah, sorry, duh, all the more confusing code tho :)

TheBlueMatt

Okay, thanks for rewriting this four times 😅. Feel free to squash (looks like the latest fixup needs to get moved back a bit), I think this LGTM. cc @wpaulino

TheBlueMatt · 2025-09-02T17:47:06Z

Also sadly needs rebase.

tankyleo · 2025-09-02T22:06:41Z

First rebase: no diff, squash fixups, reorganize commits.

As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

`NextCommitmentStats` provides the commitment transaction fee as a separate value to assist with applying a multiplier on it in `can_accept_incoming_htlc`. Nonetheless in most cases, we want the balances to include the commitment transaction fee, so here we add a helper that gives us these balances. Also make the style of `tx_builder::subtract_addl_outputs` consistent with `get_balances_including_fee`.

The reserve we should maintain on our own transaction should be greater than our own dust limit.

We check this when validating `splice_init`, `splice_ack` messages, and also when validating user-specified contributions. From BOLT 2: ``` - If `funding_contribution_satoshis` is negative and its absolute value is greater than the sending node's current channel balance: - MUST send a `warning` and close the connection or send an `error` and fail the channel. ``` and further down: ``` If a side does not meet the reserve requirements, that's OK: but if they take funds out of the channel, they must ensure that they do meet them. If your peer adds a massive amount to the channel, then you only have to add more reserve if you want to contribute to the splice (and you can use `tx_remove_output` and/or `tx_remove_input` part-way through if this happens). ``` Therefore, we check the v2 reserve anytime `funding_contribution_satoshis` is not equal to zero. We allow parties to draw from their previous reserve, as long as they satisfy their v2 reserve.

tankyleo · 2025-09-02T22:45:06Z

Second rebase: move base commit to bf87832 , use inline format arguments in some places.

TheBlueMatt

One question, otherwise LGTM

TheBlueMatt · 2025-09-03T14:31:50Z

 // New reserve values are based on the new channel value and are v2-specific
- let counterparty_selected_channel_reserve_satoshis = Some(get_v2_channel_reserve_satoshis(
+ let counterparty_selected_channel_reserve_satoshis =
+ Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));


Wait, I thin this is wrong (and also maybe reserves should be higher than both dust limits?). Not sure what the spec says, but the point of the reserve is to have something that we can be punished for when broadcasting our own stale transaction. Thus, the reserve we keep should really be higher than our own dust limit (which applies to our local commitment transactions that we can broadcast) so that if we broadcast a stale state we can be punished.

Isn't that what we have here ?
MIN_CHAN_DUST_LIMIT_SATOSHIS: our own dust limit
counterparty_selected_channel_reserve_satoshis: we must keep at least these many sats "punishable" on our broadcastable transaction.

tankyleo · 2025-08-14T01:21:41Z

 Check v2 reserves after `funding_contribution_satoshis` is applied
We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.
From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```
and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```
Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.
We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

ldk-reviews-bot · 2025-08-14T01:21:43Z

👋 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-08-14T01:31:40Z

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (bf87832) to head (85a02ca).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/tx_builder.rs	38.09%	13 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4011 +/- ##
==========================================
+ Coverage 88.76% 88.77% +0.01% 
==========================================
Files 176 176 Lines 129345 129357 +12 Branches 129345 129357 +12 ==========================================
+ Hits 114812 114836 +24 + Misses 11925 11921 -4 + Partials 2608 2600 -8

Flag	Coverage Δ
fuzzing	`22.00% <23.80%> (-0.01%)`	⬇️
tests	`88.60% <38.09%> (+0.01%)`	⬆️

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-16T01:25:45Z

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

ldk-reviews-bot · 2025-08-18T01:26:28Z

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

tankyleo · 2025-08-19T18:02:47Z

On hold until splice-out PR gets in.

ldk-reviews-bot · 2025-08-20T01:27:13Z

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

ldk-reviews-bot · 2025-08-26T23:35:08Z

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

tankyleo · 2025-08-27T02:30:54Z

Rebase on merge-base (diff):

Always run the reserve check, not just when the funding contribution is negative.
Make sure that the funder of the channel can pay for an additional nondust HTLC after the contributions are applied.
Emit WarnAndDisconnect if the balance is exhausted.
Style improvements.

tankyleo · 2025-08-27T05:54:02Z

Amend: (diff)

Run the reserve check anytime the funding contribution is not zero.

tankyleo · 2025-08-27T16:27:00Z

Rebasing now to fix conflict...

TheBlueMatt · 2025-09-01T20:24:50Z

- let their_channel_balance = Amount::from_sat(self.funding.get_value_satoshis())
- - Amount::from_sat(self.funding.get_value_to_self_msat() / 1000);
- let post_channel_balance = AddSigned::checked_add_signed(
+ let adjusted_funding_contribution = if let Some((contribution, is_initiator, feerate)) =


Are we sure this is right in the splice_ack case? In the splice_channel (initiate outbound splice) case, we pass the total contribution ignoring fees, which then mandates that we subtract the fee here. But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here. IMO we should pull this back out to the splice_channel method and keep this method strictly a symmetrical splice validation function that doesn't have any sender/recipient-specific logic at all. Once we make get_next_{local,remote}_commitment_stats fallible it'll just be a matter of calling that and checking the reserve, basically.

Will look into it thank you
But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here.
When we receive splice_ack, we set this triple to None, and we don't subtract the fee here ?
I'll revisit this part in any case.

Ah, sorry, duh, all the more confusing code tho :)

TheBlueMatt

Okay, thanks for rewriting this four times 😅. Feel free to squash (looks like the latest fixup needs to get moved back a bit), I think this LGTM. cc @wpaulino

TheBlueMatt · 2025-09-02T17:47:06Z

Also sadly needs rebase.

tankyleo · 2025-09-02T22:06:41Z

First rebase: no diff, squash fixups, reorganize commits.

As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

`NextCommitmentStats` provides the commitment transaction fee as a separate value to assist with applying a multiplier on it in `can_accept_incoming_htlc`. Nonetheless in most cases, we want the balances to include the commitment transaction fee, so here we add a helper that gives us these balances. Also make the style of `tx_builder::subtract_addl_outputs` consistent with `get_balances_including_fee`.

The reserve we should maintain on our own transaction should be greater than our own dust limit.

We check this when validating `splice_init`, `splice_ack` messages, and also when validating user-specified contributions. From BOLT 2: ``` - If `funding_contribution_satoshis` is negative and its absolute value is greater than the sending node's current channel balance: - MUST send a `warning` and close the connection or send an `error` and fail the channel. ``` and further down: ``` If a side does not meet the reserve requirements, that's OK: but if they take funds out of the channel, they must ensure that they do meet them. If your peer adds a massive amount to the channel, then you only have to add more reserve if you want to contribute to the splice (and you can use `tx_remove_output` and/or `tx_remove_input` part-way through if this happens). ``` Therefore, we check the v2 reserve anytime `funding_contribution_satoshis` is not equal to zero. We allow parties to draw from their previous reserve, as long as they satisfy their v2 reserve.

tankyleo · 2025-09-02T22:45:06Z

Second rebase: move base commit to bf87832 , use inline format arguments in some places.

TheBlueMatt

One question, otherwise LGTM

TheBlueMatt · 2025-09-03T14:31:50Z

 // New reserve values are based on the new channel value and are v2-specific
- let counterparty_selected_channel_reserve_satoshis = Some(get_v2_channel_reserve_satoshis(
+ let counterparty_selected_channel_reserve_satoshis =
+ Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));


Wait, I thin this is wrong (and also maybe reserves should be higher than both dust limits?). Not sure what the spec says, but the point of the reserve is to have something that we can be punished for when broadcasting our own stale transaction. Thus, the reserve we keep should really be higher than our own dust limit (which applies to our local commitment transactions that we can broadcast) so that if we broadcast a stale state we can be punished.

Isn't that what we have here ?
MIN_CHAN_DUST_LIMIT_SATOSHIS: our own dust limit
counterparty_selected_channel_reserve_satoshis: we must keep at least these many sats "punishable" on our broadcastable transaction.

tankyleo · 2025-08-14T01:21:41Z

 Check v2 reserves after `funding_contribution_satoshis` is applied
We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.
From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```
and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```
Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.
We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

ldk-reviews-bot · 2025-08-14T01:21:43Z

👋 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-08-14T01:31:40Z

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (bf87832) to head (85a02ca).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/tx_builder.rs	38.09%	13 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4011 +/- ##
==========================================
+ Coverage 88.76% 88.77% +0.01% 
==========================================
Files 176 176 Lines 129345 129357 +12 Branches 129345 129357 +12 ==========================================
+ Hits 114812 114836 +24 + Misses 11925 11921 -4 + Partials 2608 2600 -8

Flag	Coverage Δ
fuzzing	`22.00% <23.80%> (-0.01%)`	⬇️
tests	`88.60% <38.09%> (+0.01%)`	⬆️

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-16T01:25:45Z

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

ldk-reviews-bot · 2025-08-18T01:26:28Z

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

tankyleo · 2025-08-19T18:02:47Z

On hold until splice-out PR gets in.

ldk-reviews-bot · 2025-08-20T01:27:13Z

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

ldk-reviews-bot · 2025-08-26T23:35:08Z

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

tankyleo · 2025-08-27T02:30:54Z

Rebase on merge-base (diff):

Always run the reserve check, not just when the funding contribution is negative.
Make sure that the funder of the channel can pay for an additional nondust HTLC after the contributions are applied.
Emit WarnAndDisconnect if the balance is exhausted.
Style improvements.

tankyleo · 2025-08-27T05:54:02Z

Amend: (diff)

Run the reserve check anytime the funding contribution is not zero.

tankyleo · 2025-08-27T16:27:00Z

Rebasing now to fix conflict...

TheBlueMatt · 2025-09-01T20:24:50Z

- let their_channel_balance = Amount::from_sat(self.funding.get_value_satoshis())
- - Amount::from_sat(self.funding.get_value_to_self_msat() / 1000);
- let post_channel_balance = AddSigned::checked_add_signed(
+ let adjusted_funding_contribution = if let Some((contribution, is_initiator, feerate)) =


Are we sure this is right in the splice_ack case? In the splice_channel (initiate outbound splice) case, we pass the total contribution ignoring fees, which then mandates that we subtract the fee here. But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here. IMO we should pull this back out to the splice_channel method and keep this method strictly a symmetrical splice validation function that doesn't have any sender/recipient-specific logic at all. Once we make get_next_{local,remote}_commitment_stats fallible it'll just be a matter of calling that and checking the reserve, basically.

Will look into it thank you
But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here.
When we receive splice_ack, we set this triple to None, and we don't subtract the fee here ?
I'll revisit this part in any case.

Ah, sorry, duh, all the more confusing code tho :)

TheBlueMatt

Okay, thanks for rewriting this four times 😅. Feel free to squash (looks like the latest fixup needs to get moved back a bit), I think this LGTM. cc @wpaulino

TheBlueMatt · 2025-09-02T17:47:06Z

Also sadly needs rebase.

tankyleo · 2025-09-02T22:06:41Z

First rebase: no diff, squash fixups, reorganize commits.

As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

`NextCommitmentStats` provides the commitment transaction fee as a separate value to assist with applying a multiplier on it in `can_accept_incoming_htlc`. Nonetheless in most cases, we want the balances to include the commitment transaction fee, so here we add a helper that gives us these balances. Also make the style of `tx_builder::subtract_addl_outputs` consistent with `get_balances_including_fee`.

The reserve we should maintain on our own transaction should be greater than our own dust limit.

We check this when validating `splice_init`, `splice_ack` messages, and also when validating user-specified contributions. From BOLT 2: ``` - If `funding_contribution_satoshis` is negative and its absolute value is greater than the sending node's current channel balance: - MUST send a `warning` and close the connection or send an `error` and fail the channel. ``` and further down: ``` If a side does not meet the reserve requirements, that's OK: but if they take funds out of the channel, they must ensure that they do meet them. If your peer adds a massive amount to the channel, then you only have to add more reserve if you want to contribute to the splice (and you can use `tx_remove_output` and/or `tx_remove_input` part-way through if this happens). ``` Therefore, we check the v2 reserve anytime `funding_contribution_satoshis` is not equal to zero. We allow parties to draw from their previous reserve, as long as they satisfy their v2 reserve.

tankyleo · 2025-09-02T22:45:06Z

Second rebase: move base commit to bf87832 , use inline format arguments in some places.

TheBlueMatt

One question, otherwise LGTM

TheBlueMatt · 2025-09-03T14:31:50Z

 // New reserve values are based on the new channel value and are v2-specific
- let counterparty_selected_channel_reserve_satoshis = Some(get_v2_channel_reserve_satoshis(
+ let counterparty_selected_channel_reserve_satoshis =
+ Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));


Wait, I thin this is wrong (and also maybe reserves should be higher than both dust limits?). Not sure what the spec says, but the point of the reserve is to have something that we can be punished for when broadcasting our own stale transaction. Thus, the reserve we keep should really be higher than our own dust limit (which applies to our local commitment transactions that we can broadcast) so that if we broadcast a stale state we can be punished.

Isn't that what we have here ?
MIN_CHAN_DUST_LIMIT_SATOSHIS: our own dust limit
counterparty_selected_channel_reserve_satoshis: we must keep at least these many sats "punishable" on our broadcastable transaction.

tankyleo · 2025-08-14T01:21:41Z

 Check v2 reserves after `funding_contribution_satoshis` is applied
We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.
From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```
and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```
Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.
We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

ldk-reviews-bot · 2025-08-14T01:21:43Z

👋 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-08-14T01:31:40Z

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (bf87832) to head (85a02ca).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/tx_builder.rs	38.09%	13 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4011 +/- ##
==========================================
+ Coverage 88.76% 88.77% +0.01% 
==========================================
Files 176 176 Lines 129345 129357 +12 Branches 129345 129357 +12 ==========================================
+ Hits 114812 114836 +24 + Misses 11925 11921 -4 + Partials 2608 2600 -8

Flag	Coverage Δ
fuzzing	`22.00% <23.80%> (-0.01%)`	⬇️
tests	`88.60% <38.09%> (+0.01%)`	⬆️

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-16T01:25:45Z

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

ldk-reviews-bot · 2025-08-18T01:26:28Z

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

tankyleo · 2025-08-19T18:02:47Z

On hold until splice-out PR gets in.

ldk-reviews-bot · 2025-08-20T01:27:13Z

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

ldk-reviews-bot · 2025-08-26T23:35:08Z

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

tankyleo · 2025-08-27T02:30:54Z

Rebase on merge-base (diff):

Always run the reserve check, not just when the funding contribution is negative.
Make sure that the funder of the channel can pay for an additional nondust HTLC after the contributions are applied.
Emit WarnAndDisconnect if the balance is exhausted.
Style improvements.

tankyleo · 2025-08-27T05:54:02Z

Amend: (diff)

Run the reserve check anytime the funding contribution is not zero.

tankyleo · 2025-08-27T16:27:00Z

Rebasing now to fix conflict...

TheBlueMatt · 2025-09-01T20:24:50Z

- let their_channel_balance = Amount::from_sat(self.funding.get_value_satoshis())
- - Amount::from_sat(self.funding.get_value_to_self_msat() / 1000);
- let post_channel_balance = AddSigned::checked_add_signed(
+ let adjusted_funding_contribution = if let Some((contribution, is_initiator, feerate)) =


Are we sure this is right in the splice_ack case? In the splice_channel (initiate outbound splice) case, we pass the total contribution ignoring fees, which then mandates that we subtract the fee here. But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here. IMO we should pull this back out to the splice_channel method and keep this method strictly a symmetrical splice validation function that doesn't have any sender/recipient-specific logic at all. Once we make get_next_{local,remote}_commitment_stats fallible it'll just be a matter of calling that and checking the reserve, basically.

Will look into it thank you
But then we go to test again in splice_ack and, AFAICT we pass the adjusted contribution at that point (which is what we send to our counterparty, or the their_funding_contribution used below), and then we shouldn't subtract the fee here.
When we receive splice_ack, we set this triple to None, and we don't subtract the fee here ?
I'll revisit this part in any case.

Ah, sorry, duh, all the more confusing code tho :)

TheBlueMatt

Okay, thanks for rewriting this four times 😅. Feel free to squash (looks like the latest fixup needs to get moved back a bit), I think this LGTM. cc @wpaulino

TheBlueMatt · 2025-09-02T17:47:06Z

Also sadly needs rebase.

tankyleo · 2025-09-02T22:06:41Z

First rebase: no diff, squash fixups, reorganize commits.

As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

`NextCommitmentStats` provides the commitment transaction fee as a separate value to assist with applying a multiplier on it in `can_accept_incoming_htlc`. Nonetheless in most cases, we want the balances to include the commitment transaction fee, so here we add a helper that gives us these balances. Also make the style of `tx_builder::subtract_addl_outputs` consistent with `get_balances_including_fee`.

The reserve we should maintain on our own transaction should be greater than our own dust limit.

We check this when validating `splice_init`, `splice_ack` messages, and also when validating user-specified contributions. From BOLT 2: ``` - If `funding_contribution_satoshis` is negative and its absolute value is greater than the sending node's current channel balance: - MUST send a `warning` and close the connection or send an `error` and fail the channel. ``` and further down: ``` If a side does not meet the reserve requirements, that's OK: but if they take funds out of the channel, they must ensure that they do meet them. If your peer adds a massive amount to the channel, then you only have to add more reserve if you want to contribute to the splice (and you can use `tx_remove_output` and/or `tx_remove_input` part-way through if this happens). ``` Therefore, we check the v2 reserve anytime `funding_contribution_satoshis` is not equal to zero. We allow parties to draw from their previous reserve, as long as they satisfy their v2 reserve.

tankyleo · 2025-09-02T22:45:06Z

Second rebase: move base commit to bf87832 , use inline format arguments in some places.

TheBlueMatt

One question, otherwise LGTM

TheBlueMatt · 2025-09-03T14:31:50Z

 // New reserve values are based on the new channel value and are v2-specific
- let counterparty_selected_channel_reserve_satoshis = Some(get_v2_channel_reserve_satoshis(
+ let counterparty_selected_channel_reserve_satoshis =
+ Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));


Wait, I thin this is wrong (and also maybe reserves should be higher than both dust limits?). Not sure what the spec says, but the point of the reserve is to have something that we can be punished for when broadcasting our own stale transaction. Thus, the reserve we keep should really be higher than our own dust limit (which applies to our local commitment transactions that we can broadcast) so that if we broadcast a stale state we can be punished.

Isn't that what we have here ?
MIN_CHAN_DUST_LIMIT_SATOSHIS: our own dust limit
counterparty_selected_channel_reserve_satoshis: we must keep at least these many sats "punishable" on our broadcastable transaction.

tankyleo changed the title ~~Validate negative funding contributions in splice_ack and splice_init messages~~Validate negative funding contributions in splice_init and splice_ack messagesAug 14, 2025

tankyleo force-pushed the splice-reserve-check branch from 6d6b07c to 93965c6Compare August 14, 2025 01:24

tankyleo requested a review from wpaulino August 14, 2025 01:25

tankyleo added this to Weekly Goals Aug 14, 2025

tankyleo self-assigned this Aug 14, 2025

wpaulino mentioned this pull request Aug 18, 2025
Add splice-out support #3979
Merged

tankyleo removed the request for review from wpaulino August 20, 2025 01:37

tankyleo marked this pull request as draft August 20, 2025 01:38

jkczyz mentioned this pull request Aug 21, 2025
Dual-funded channels and Splicing Project Tracking #1621
Closed
7 tasks

tankyleo force-pushed the splice-reserve-check branch from 93965c6 to d0023e3Compare August 26, 2025 22:14

tankyleo marked this pull request as ready for review August 26, 2025 22:14

ldk-reviews-bot requested a review from valentinewallace August 26, 2025 22:15

tankyleo requested review from wpaulino and removed request for valentinewallace August 26, 2025 22:15

wpaulino reviewed Aug 26, 2025
View reviewed changes

tankyleo force-pushed the splice-reserve-check branch from d0023e3 to 835b67bCompare August 27, 2025 02:26

tankyleo requested a review from wpaulino August 27, 2025 02:37

tankyleo changed the title ~~Validate negative funding contributions in splice_init and splice_ack messages~~Validate funding contributions reserves in splice_init and splice_ack handlingAug 27, 2025

tankyleo force-pushed the splice-reserve-check branch from 835b67b to 453a211Compare August 27, 2025 05:51

graphite-appBot reviewed Aug 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs Outdated

tankyleo requested review from TheBlueMatt and removed request for TheBlueMatt August 31, 2025 22:04

graphite-appBot reviewed Aug 31, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/channel.rs Outdated

tankyleo force-pushed the splice-reserve-check branch 2 times, most recently from 8b3004e to ce4161cCompare September 1, 2025 07:38

TheBlueMatt reviewed Sep 1, 2025
View reviewed changes

TheBlueMatt added this to the 0.2 milestone Sep 1, 2025

tankyleo force-pushed the splice-reserve-check branch from 1ce710f to b6757a5Compare September 2, 2025 07:23

tankyleo requested a review from TheBlueMatt September 2, 2025 07:25

TheBlueMatt reviewed Sep 2, 2025
View reviewed changes

tankyleo force-pushed the splice-reserve-check branch from b6757a5 to c96dba4Compare September 2, 2025 22:05

tankyleo added 7 commits September 2, 2025 22:07

Finish validation in splice_ack before taking a &mut self
a4796a4
As much as possible, we want to only mutate state once we are done with input validation. This also removes complaints when helper functions during validation take a `&self`.

Add validate_splice_ack helper function
35d6f65
As in `splice_init`, this helps clearly delineate `splice_ack` message validation from the subsequent state mutations. This is a code-move.

Make for_splice infallible
bfa0f95

Correct the reserve minimums in FundingScope::for_splice
917ee4a
The reserve we should maintain on our own transaction should be greater than our own dust limit.

Enforce that the splice initiator set a non-zero funding contribution
b5cf08d

tankyleo force-pushed the splice-reserve-check branch from c96dba4 to 85a02caCompare September 2, 2025 22:40

tankyleo requested review from TheBlueMatt and wpaulino September 2, 2025 22:46

graphite-appBot reviewed Sep 2, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

wpaulino approved these changes Sep 2, 2025
View reviewed changes

TheBlueMatt approved these changes Sep 3, 2025
View reviewed changes

TheBlueMatt merged commit 9ddd25b into lightningdevkit:mainSep 3, 2025
25 checks passed

github-project-automationBot moved this from Goal: Merge to Done in Weekly Goals Sep 3, 2025