Twin: synonymdev/bitkit-android#1388
What happened?
After a channel is opened to Bitkit, Receive offers the full receiving capacity of the channel, but a single incoming Lightning payment can only use about a tenth of it. A payment above 10% of the channel size is not received: the sender gets no route, or a timeout when the payment is split, and Bitkit shows nothing.
Bitkit answers the channel open with max_htlc_value_in_flight_msat set to 10% of the channel value. LDK's default for inbound channels is 10%, and ldk-node raises it to 100% only for an LSPS2 service or an LSPS2 client peer (builder.rs and event.rs at the pinned revision, 190a17d). LightningService.swift configures neither, and Bitkit cannot announce channels (no node alias, no listening addresses), so every channel it accepts keeps the 10% limit. The limit covers all in-flight HTLCs of the channel together, so splitting the payment does not help.
Seen on iOS in a demo run on 24 Sep (iOS Simulator wallet, a channel Blocktank opened on staging regtest): on a 1,253,011 sat channel the node told the LSP it would accept at most 125,301 sats in flight (max_htlc_value_in_flight_msat: 125301100, quoted from that run's log). No payment above that was attempted on iOS; the payment failure is reproduced on Android regtest (twin issue).
A channel keeps the limit it was opened with, so channels that exist today stay capped after the fix. Only channels opened after updating get the full value.
Expected behavior
An incoming payment succeeds up to the receiving capacity of the channel, not only up to 10% of it.
Steps to Reproduce
From the Android reproduction; not run on iOS.
- Open a channel to Bitkit (Blocktank order, or a regtest LND with a private channel).
- Pay Bitkit an invoice for 9% of the channel size: succeeds.
- Pay Bitkit an invoice for 11% of the channel size: fails.
Logs / Screenshots / Recordings
The iOS run above is from the AcceptChannel line in the app log. The same ldk-node revision (0.7.0-rc.66) is pinned on Android, where the payment failure was reproduced on regtest: 90,000 sats (9%) succeeds; 110,000 sats (11%) fails with FAILURE_REASON_NO_ROUTE from a single shard, or with commitment transaction exceed maxoverall pending htlc value and a final timeout when the payment splits. Details in the twin issue. The iOS build itself was not re-run on regtest.
Bitkit Version
Demo build of 24 Sep with ldk-node 0.7.0-rc.66; the node config code is unchanged on master (c5a2a05). The payment failure is reproduced on Android only.
Device / OS
iOS Simulator.
Reproducibility
Always
Fix
Twin: synonymdev/bitkit-android#1388
What happened?
After a channel is opened to Bitkit, Receive offers the full receiving capacity of the channel, but a single incoming Lightning payment can only use about a tenth of it. A payment above 10% of the channel size is not received: the sender gets no route, or a timeout when the payment is split, and Bitkit shows nothing.
Bitkit answers the channel open with
max_htlc_value_in_flight_msatset to 10% of the channel value. LDK's default for inbound channels is 10%, and ldk-node raises it to 100% only for an LSPS2 service or an LSPS2 client peer (builder.rsandevent.rsat the pinned revision,190a17d).LightningService.swiftconfigures neither, and Bitkit cannot announce channels (no node alias, no listening addresses), so every channel it accepts keeps the 10% limit. The limit covers all in-flight HTLCs of the channel together, so splitting the payment does not help.Seen on iOS in a demo run on 24 Sep (iOS Simulator wallet, a channel Blocktank opened on staging regtest): on a 1,253,011 sat channel the node told the LSP it would accept at most 125,301 sats in flight (
max_htlc_value_in_flight_msat: 125301100, quoted from that run's log). No payment above that was attempted on iOS; the payment failure is reproduced on Android regtest (twin issue).A channel keeps the limit it was opened with, so channels that exist today stay capped after the fix. Only channels opened after updating get the full value.
Expected behavior
An incoming payment succeeds up to the receiving capacity of the channel, not only up to 10% of it.
Steps to Reproduce
From the Android reproduction; not run on iOS.
Logs / Screenshots / Recordings
The iOS run above is from the AcceptChannel line in the app log. The same ldk-node revision (
0.7.0-rc.66) is pinned on Android, where the payment failure was reproduced on regtest: 90,000 sats (9%) succeeds; 110,000 sats (11%) fails withFAILURE_REASON_NO_ROUTEfrom a single shard, or withcommitment transaction exceed maxoverall pending htlc valueand a final timeout when the payment splits. Details in the twin issue. The iOS build itself was not re-run on regtest.Bitkit Version
Demo build of 24 Sep with ldk-node 0.7.0-rc.66; the node config code is unchanged on
master(c5a2a05). The payment failure is reproduced on Android only.Device / OS
iOS Simulator.
Reproducibility
Always
Fix