fix: rescale HTLC in-flight caps on splice promotion#17
Open
martinsaposnic wants to merge 1 commit intolsp-0.2.0_accept-underpaying-htlcs_with_timing_logsfrom
Open
Conversation
When a splice promotes a new FundingScope, `holder_max_htlc_value_in_flight_msat` and `counterparty_max_htlc_value_in_flight_msat` stay pinned at their pre-splice values instead of scaling with the new channel capacity. Any HTLC larger than the pre-splice cap is rejected: - on the sender with HTLCMaximum inside send_htlc - on the receiver with "Remote HTLC add would put them over our max HTLC value", which force-closes the channel Both manifestations break LSPS4 JIT splice flows where the client's embedded node first opens a small JIT channel, then splices in capacity when a larger payment arrives. The receiver force-close is particularly damaging because it destroys the channel along with any pending fees. Rescale both caps proportionally to the channel-value change on splice promotion. Also tightens the test_splice_in assertions (the previous check compared msats to sats).
amackillop
approved these changes
Apr 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Cherry-pick of #15 onto the
lsp-0.2.0_accept-underpaying-htlcs_with_timing_logsbranch.This is the rust-lightning branch actually consumed by
@moneydevkit/lightning-js(via ldk-node branchlsp-0.7.0_accept-underpaying-htlcs_with_timing_logs, rev4309f479, which pins rust-lightning rev070b31d93). Without this fix merged HERE, every lightning-js build on npm force-closes channels on splice in production.Fixes HTLC-in-flight caps not being recomputed on splice promotion. Without this, any HTLC larger than the pre-splice channel's advertised cap is rejected after a splice-in, breaking LSPS4 JIT splice flows.
Symptoms observed
HTLCMaximuminsidesend_htlc, surfaces asTemporaryChannelFailure(0x1007)to the payer.Remote HTLC add would put them over our max HTLC value (<pre-splice cap>), force-closes the channel.The receiver case is the severe one: channel lost along with any pending fees. Because lightning-js runs on the client/receiver side, this branch is where the receiver-side fix lands.
Root cause
On splice promotion (the
core::mem::swap(&mut self.funding, funding)in channel.rs),holder_max_htlc_value_in_flight_msatandcounterparty_max_htlc_value_in_flight_msatstay pinned at their pre-splice values. The assumption thatchannel_valueis immutable no longer holds once splicing is in play.Fix
Rescale both caps proportionally to the channel-value change on splice promotion. Also tightens
test_splice_in's assertion (it compared msats to sats and passed vacuously).E2E validation
Full regtest run with LSPS4 JIT splice, LSP on #15 + client (bitcoin-ibd) on this patch:
Pre-fix: receiver force-closed the channel on the 80k splice payment.
Checklist