Contribute to splice as acceptor

[jkczyz]

When both nodes want to splice simultaneously, the quiescence tie-breaker designates one as the initiator. Previously, the losing node responded with zero contribution, requiring a second full splice session after the first splice locked. This is wasteful, especially for often-offline nodes that may connect and immediately want to splice.

Instead, the losing node contributes to the winner's splice as the acceptor, merging both contributions into a single splice transaction. Since the FundingContribution was originally built with initiator fees (which include common fields and shared input/output weight), the fee is adjusted to the acceptor rate before contributing, with the surplus
returned to the change output.

[ldk-reviews-bot]

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

Codecov Report

❌ Patch coverage is 94.63487% with 36 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.04%. Comparing base (24062c0) to head (834634b).
⚠️ Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/funding.rs	95.00%	15 Missing and 12 partials ⚠️
lightning/src/ln/channel.rs	92.06%	3 Missing and 2 partials ⚠️
lightning/src/ln/interactivetxs.rs	93.84%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4416      +/-   ##
==========================================
+ Coverage   85.94%   86.04%   +0.10%     
==========================================
  Files         159      159              
  Lines      104607   104978     +371     
  Branches   104607   104978     +371     
==========================================
+ Hits        89901    90327     +426     
+ Misses      12194    12142      -52     
+ Partials     2512     2509       -3     

Flag	Coverage Δ
tests	86.04% <94.63%> (+0.10%)	⬆️

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.

[wpaulino]

If we have a mixed splice where we fully consume an input and cover the remaining outstanding amount with the channel balance, then budget should probably also reflect the channel balance available to spend?

[jkczyz]

As of now, we've only allowed drawing from the channel balance in the splice-out case. Mixed mode will only use inputs.

Outsourcing this idea to Claude, it would be possible but has some implications. We can discuss but I'd rather leave this to a follow-up as it would change the current behavior.

❯ What are the implications of allowing the fees to be absorbed by the      
  channel balance in this case? Is it possible to do? What code changes     
  would be involved?                                                        

⏺ Let me trace how net_value flows through the protocol to understand the
  implications.

⏺ Searched for 2 patterns (ctrl+o to expand)

⏺ Now let me look at how our_funding_contribution is used in
  validate_splice_contributions and the interactive TX setup.

⏺ Searched for 1 pattern (ctrl+o to expand)

⏺ Now let me see how our_funding_contribution flows into
  FundingScope::for_splice and how it affects the shared output value.

⏺ Searched for 1 pattern (ctrl+o to expand)

⏺ This is the key piece. our_funding_contribution (which is net_value())
  directly determines:
  1. post_channel_value — the new total channel capacity
  2. post_value_to_self_msat — our balance in the new channel (line 2794-2796:
  value_to_self_msat + our_funding_contribution * 1000)

  Now let me check how the acceptor path uses net_value_for_acceptor_at_feerate
  vs net_value to understand the current split.

⏺ Read 1 file (ctrl+o to expand)

⏺ Here's what I've found:

  How net_value is used: our_funding_contribution (from net_value() or
  net_value_for_acceptor_at_feerate()) flows into FundingScope::for_splice where
   it directly determines:
  - post_channel_value — the new channel capacity
  - value_to_self_msat — our balance (line 2796: prev_value_to_self + 
  our_funding_contribution * 1000)

  Current behavior for with-inputs case: net_value_with_fee returns value_added 
  - value_removed regardless of estimated_fee, because unpaid_fees = 0 when
  inputs are present. So our_funding_contribution is fixed — feerate changes
  don't affect it.

  Current behavior for no-inputs case (pure splice-out): net_value_with_fee
  returns -value_removed - estimated_fee. The fee IS deducted from channel
  balance. And compute_feerate_adjustment in the no-inputs branch (line 504-521)
   freely allows the surplus to go back to channel balance — there's no strict
  budget constraint, just a check that estimated_fee >= fair_fee.

  The question for mixed mode: Could we let the channel balance absorb fee
  increases when inputs can't cover them?

  Yes, it's possible, but here's what it would mean:

  1. net_value would become feerate-dependent even with inputs. Instead of
  value_added - value_removed, it would be something like value_added - 
  value_removed - unpaid_fee_delta. This changes our_funding_contribution, which
   changes both the channel capacity and our balance.
  2. The user's intended contribution silently changes. If someone asks for
  splice_in_and_out(10k, [80k output]), they expect net = -70k. If we absorb 500
   sats of extra fee from channel balance, net becomes -70,500. The user's
  channel balance decreases by an extra 500 sats beyond what they requested.
  3. Code changes required:
    - compute_feerate_adjustment would need a new branch (or extension of the
  inputs branch) that, when the inputs budget is insufficient, computes how much
   extra fee the channel balance can absorb
    - net_value_with_fee would need to change: instead of unpaid_fees = 0 when
  inputs are present, it would need to compute the portion of fees not covered
  by inputs
    - for_acceptor_at_feerate would need to propagate this adjusted net value
    - net_value_for_acceptor_at_feerate already uses
  net_value_with_fee(new_estimated_fee) — this would need to account for the
  split between input-paid and balance-paid fees
    - Tests asserting net_value is stable across feerate changes for splice-in
  would need updating
  4. Protocol implication: The splice_ack.funding_contribution_satoshis message
  communicates our net contribution. If our contribution changes due to the
  initiator's feerate, the value we send in splice_ack must reflect the adjusted
   amount. Currently splice_init computes the adjusted our_funding_contribution
  via net_value_for_acceptor_at_feerate before sending splice_ack, so the
  plumbing exists — it just returns the same value today for the with-inputs
  case.

  Bottom line: It's technically feasible but it changes the semantics of the
  user's contribution. The current behavior (fail if inputs can't cover the fee
  increase) is arguably more correct — it tells the user "your contribution
  can't accommodate this feerate" rather than silently taking more from their
  channel balance. The pure splice-out case is different because there, fees
  from channel balance are the only fee mechanism, so flexibility is expected.

  Does this answer your question, or are you considering making a change here?

✻ Baked for 49s

[TheBlueMatt]

In both the no-input and no-change case we fail if we'd pay a fee higher than our initially-estimated fee, but here we'll happily continue even if we'd end up reducing change or even removing it. ISTM we should maybe fail instead, as we'd maybe prefer to do our own splice with our own feerate on top of the counterparty's splice later or even splice on another channel instead instead of paying more in fees. Its complicated though, for someone with only a single channel who wants to pay immediately they'd prefer it to work, but in that setup there's a chance that the counterparty just beats them to the punch anyway, so maybe its "something they have to deal with either way" and its fine?

[jkczyz]

Right, related to my response to one of @wpaulino's comments, perhaps the user needs to indicate a max fee rate for these scenarios? Otherwise, it seems we'd never contribute as an acceptor.

[jkczyz]

Also, note that if the user-specified min/max fee rate is tight, we could reject if the counterparty gives a fee rate slightly above the max even though we may pay less fees since we wouldn't be paying for common fields and shared input / output. So that would need to be considered.

[jkczyz]

Updated now. PTAL.

[jkczyz]

Latest push:

• squashes fixups
• fixes fuzz and lint CI failures
• makes FeeRateAdjustmentError more structured so we don't need to allocate a string just to print the error

[wpaulino]

Let's add docs for why we require both min and max

[jkczyz]

Done.

[wpaulino]

It's not always the change output, it could be our channel balance in a splice out.

[jkczyz]

Updated all docs.

[wpaulino]

Looks like we'd need to know the channel balance here to see if we can afford going higher?

[jkczyz]

Yeah, you're right. Re-worked though when get_holder_counterparty_balances_floor_incl_fee returns an error we skip the contribution. Not sure if you prefer something else. For RBF, we can't really skip if it's our previous contribution, so we'd have to fail the RBF.

[wpaulino]

In practice, this case should never work out, right? Not having a change output implies that we had a ~perfect match, so even a slight change in feerate would either result in needing another input or needing a change output.

[jkczyz]

The change could have been burned to the miner and possibly could still be if only slightly different. The feerate isn't the only thing that matters though, as an acceptor you pay for less weight than if you are the initiator. Added a test exercising this code path.