Add AvailableBalances::next_splice_out_maximum_sat

[tankyleo]

This is the maximum value the holder can splice out of their channel balance, accounting for the updated v2 reserves after the splice, and the "must have at least one output" constraint on zero-reserve channels.

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

[ldk-claude-review-bot]

Review Summary

Correction of Prior Comments

My previous review flagged three "unit mismatch" bugs that were incorrect:

• channel_state.rs:628 — The TLV default already divides by 1000: u64::from(outbound_capacity_msat.0.unwrap()) / 1000
• router.rs:4153 — The test helper already uses outbound_capacity_msat / 1000
• router.rs:9653 — The value 10_000_000 is already correct (10_000_000_000 / 1000)

I apologize for the false positives.

Still-Valid Prior Comments

The following prior comments remain valid concerns:

• lightning/src/sign/tx_builder.rs:414 — get_next_splice_out_maximum_sat checks has_output only on the local commitment (using holder_dust_limit). If counterparty_dust_limit > holder_dust_limit in a zero-reserve channel, the remote commitment could have no outputs, causing the debug assertion unwrap() at channel.rs:13419 to panic.

• lightning/src/sign/tx_builder.rs:355 — dust_limit_max_splice_out_sat uses holder_dust_limit_satoshis as the floor, while validate_splice_contributions uses MIN_CHAN_DUST_LIMIT_SATOSHIS (354). For channels deserialized from older LDK versions where holder_dust_limit could be 546, the debug assertion unwrap_err() at channel.rs:13425 could panic.

• lightning/src/ln/channel.rs:13426 — Debug assertions rely on exact agreement between get_next_splice_out_maximum_sat and validate_splice_contributions, but the two have subtle inconsistencies in dust limit handling and commitment selection.

• lightning/src/sign/tx_builder.rs:391 — Comment says "bump this maximum" when the code actually reduces it.

New Issues Found

No new issues found beyond those already covered by prior comments. The equation derivation for the v2 reserve constraint is correct, the feerate spike handling is consistent (no double-spike in the validation path), the accumulator logic for multi-funding channels correctly takes the minimum, and the semantic change from "holder balance floor" to "max splice-out" in resolve_queued_contribution and build_prior_contribution is appropriate since downstream consumers (compute_feerate_adjustment) compare total splice-out cost against this value.

[tankyleo]

Seems the fuzz failure produces this error on my machine

Hex:

ff1cb4a6a6ffffff02000000ffffb4a669696969696969691b00000000000000ffffffffffa2ad06301100ffffffffffffcf111f7d29000000000000001f0007

Target: chanmon_consistency

Error:

2      ERROR [lightning::ln::channelmanager:4635]      ch:8c0000 p:020000          Closed channel due to close-required error: Channel closed because of an exception: splice tx of another pending funding already confirmed
2      ERROR [lightning::ln::channelmanager:4557]      ch:8c0000 p:020000          Closing channel: Channel closed because of an exception: splice tx of another pending funding already confirmed