Skip to content

Enforce min_funding_satoshis after splices#4615

Open
tankyleo wants to merge 1 commit into
lightningdevkit:mainfrom
tankyleo:2026-05-splice-min-funding-satoshis
Open

Enforce min_funding_satoshis after splices#4615
tankyleo wants to merge 1 commit into
lightningdevkit:mainfrom
tankyleo:2026-05-splice-min-funding-satoshis

Conversation

@tankyleo
Copy link
Copy Markdown
Contributor

@tankyleo tankyleo commented May 15, 2026

We already enforce this minimum for inbound channels, so it makes sense to also enforce this minimum on any splices in which the counterparty's contribution is negative.

@ldk-reviews-bot
Copy link
Copy Markdown

ldk-reviews-bot commented May 15, 2026

👋 Thanks for assigning @TheBlueMatt 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.

@tankyleo tankyleo self-assigned this May 15, 2026
@tankyleo tankyleo added this to the 0.3 milestone May 15, 2026
@tankyleo tankyleo removed this from Weekly Goals May 15, 2026
@tankyleo tankyleo moved this to Goal: Merge in Weekly Goals May 15, 2026
Comment thread lightning/src/ln/channel.rs Outdated
Comment thread lightning/src/ln/channel.rs
@ldk-claude-review-bot
Copy link
Copy Markdown
Collaborator

ldk-claude-review-bot commented May 15, 2026

No issues found. The PR is clean.

Summary of review:

  • The core validation logic in FundingScope::for_splice() correctly enforces min_funding_satoshis only when all three conditions are met: (1) post-splice value is below the limit, (2) the counterparty's contribution is negative, and (3) the channel is inbound.
  • All four entry points (splice_init, splice_ack, tx_init_rbf, tx_ack_rbf) correctly thread the min_funding_satoshis parameter through from channelmanager.rs.
  • Error handling uses WarnAndDisconnect consistently, which disconnects the peer without force-closing the channel — appropriate for a policy violation.
  • The self.config.read().unwrap().channel_handshake_limits.min_funding_satoshis pattern at all four channelmanager callsites is consistent with existing config access patterns in the codebase.
  • The documentation update on ChannelHandshakeLimits::min_funding_satoshis accurately describes the new behavior.
  • The six new tests provide comprehensive coverage of all paths: splice_init (allow/reject), splice_ack (allow outbound/reject inbound), tx_init_rbf (reject), and tx_ack_rbf (reject).
  • The debug assertions in get_next_splice_out_maximum() correctly pass 0 with an explanatory comment, since those assertions use their_funding_contribution = ZERO which would never trigger the new check anyway.

No new issues found beyond what was flagged in prior review passes.

@codecov
Copy link
Copy Markdown

codecov Bot commented May 15, 2026

Codecov Report

❌ Patch coverage is 97.67442% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 86.42%. Comparing base (b8118e3) to head (6c2090d).

Files with missing lines Patch % Lines
lightning/src/ln/channel.rs 97.43% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4615      +/-   ##
==========================================
+ Coverage   86.40%   86.42%   +0.01%     
==========================================
  Files         158      158              
  Lines      109293   109324      +31     
  Branches   109293   109324      +31     
==========================================
+ Hits        94439    94487      +48     
+ Misses      12309    12297      -12     
+ Partials     2545     2540       -5     
Flag Coverage Δ
fuzzing-fake-hashes 5.07% <0.00%> (-0.01%) ⬇️
fuzzing-real-hashes 22.77% <0.00%> (-0.02%) ⬇️
tests 86.16% <97.67%> (+0.02%) ⬆️

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.

@tankyleo tankyleo force-pushed the 2026-05-splice-min-funding-satoshis branch from 861efec to 6a86bd5 Compare May 15, 2026 19:18
.ok_or(format!("The sum of contributions {our_funding_contribution} and {their_funding_contribution} is greater than the channel's value"))?;
.ok_or(format!(
"The sum of contributions {our_funding_contribution} and \
{their_funding_contribution} is greater than the channel's value"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's with the random reformatting here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

haha trying to break some long lines myself since rust fmt doesn't help, will revisit

pub(crate) fn splice_init<ES: EntropySource, L: Logger>(
&mut self, msg: &msgs::SpliceInit, entropy_source: &ES, holder_node_id: &PublicKey,
logger: &L,
min_funding_satoshis: u64, logger: &L,
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, should we maybe move the configured minimum to the channel somehow? Its kinda weird that we apply the global channel minimum to splice-outs on potentially-outbound channels. Someone might use that config to limit inbound channels to only 1 BTC + (or something very high to prevent rando nodes from opening channels) but be perfectly fine with a peer taking funds out of an existing channel. I'm generally not super convinced that re-applying this config knob to splices makes sense for uses outside of "don't allow absurdly broken channels", which is basically the use-case for the default value, but might not be for all uses of it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The case I had in mind is rando opens a fat channel to you, then withdraws past your funding limit. But agreed it's not a very strong case, can drop the PR if this use-case is not compelling.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could also apply this diff to enforce this on just inbound channels

diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index f7c7fcff7..fde56a9ad 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -2831,7 +2831,9 @@
                                {post_channel_value_sat}"
                        ));
                }
-               if post_channel_value_sat < min_funding_satoshis && their_funding_contribution.is_negative()
+               if post_channel_value_sat < min_funding_satoshis
+                       && their_funding_contribution.is_negative()
+                       && !prev_funding.is_outbound()
                {
                        return Err(format!(
                                "Spliced channel value {post_channel_value_sat} would be smaller \

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yea, maybe we just do that?

In inbound channels, we already enforce this minimum at channel open, so
it makes sense to also enforce this minimum on any splices in which the
counterparty's contribution is negative.

Codex wrote the tests.
@tankyleo tankyleo force-pushed the 2026-05-splice-min-funding-satoshis branch from 6a86bd5 to 6c2090d Compare May 15, 2026 22:51
@tankyleo tankyleo requested a review from TheBlueMatt May 15, 2026 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Goal: Merge

Development

Successfully merging this pull request may close these issues.

4 participants