Twin: synonymdev/bitkit-ios#850
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. Bitkit configures neither, and it 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.
The same limit showed on iOS in a demo run on 24 Sep (iOS Simulator, 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. That value is quoted from the run's log; no payment was attempted there.
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
- Build the regtest variant from
master with a local Electrum backend, create a wallet and fund it on-chain.
- Connect a regtest LND to Bitkit (Dev Settings, LDK Debug, Add Peer) and open a private channel of 1,000,000 sats from LND to Bitkit.
- Create an invoice in Receive and pay 90,000 sats (9%) from LND: succeeds and Bitkit shows "Received Instant Bitcoin".
- Create a new invoice and pay 110,000 sats (11%) from LND: fails.
Logs / Screenshots / Recordings
Bitkit log, answer to the channel open (10% of 1,000,000 sats):
AcceptChannel { ... max_htlc_value_in_flight_msat: 100000000, ... }
LND, single shard of 110,000 sats:
Payment status: FAILED, reason: FAILURE_REASON_NO_ROUTE
LND, payment allowed to split (the first 55,000 sat shard is accepted and held by Bitkit, the second is refused locally):
[WRN] HSWC: ChannelLink(...): Unable to handle downstream add HTLC: commitment transaction exceed maxoverall pending htlc value
Bitkit accepts the shards that fit (55,000 + 27,500 + 13,750 sats), waits for the rest and fails them after about three minutes:
Failing HTLC with payment_hash a36d2cb8... backwards from us: HTLC failure MPPTimeout error code 23
The payer's side ends as FAILURE_REASON_TIMEOUT.
With the fix (ldk-node change below, same app build otherwise) the same 1,000,000 sat channel is accepted with max_htlc_value_in_flight_msat: 1000000000, and single payments of 110,000 sats (11%) and 500,000 sats (50%) both succeed.
Bitkit Version
2.5.0 (190), dev regtest debug build from master (4d13a1d), ldk-node 0.7.0-rc.66.
Device / OS
Android emulator, Android 16 (API 36.1), arm64.
Reproducibility
Always
Fix
Twin: synonymdev/bitkit-ios#850
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. Bitkit configures neither, and it 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.The same limit showed on iOS in a demo run on 24 Sep (iOS Simulator, 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. That value is quoted from the run's log; no payment was attempted there.
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
masterwith a local Electrum backend, create a wallet and fund it on-chain.Logs / Screenshots / Recordings
Bitkit log, answer to the channel open (10% of 1,000,000 sats):
LND, single shard of 110,000 sats:
LND, payment allowed to split (the first 55,000 sat shard is accepted and held by Bitkit, the second is refused locally):
Bitkit accepts the shards that fit (55,000 + 27,500 + 13,750 sats), waits for the rest and fails them after about three minutes:
The payer's side ends as
FAILURE_REASON_TIMEOUT.With the fix (ldk-node change below, same app build otherwise) the same 1,000,000 sat channel is accepted with
max_htlc_value_in_flight_msat: 1000000000, and single payments of 110,000 sats (11%) and 500,000 sats (50%) both succeed.Bitkit Version
2.5.0 (190),
devregtest debug build frommaster(4d13a1d), ldk-node 0.7.0-rc.66.Device / OS
Android emulator, Android 16 (API 36.1), arm64.
Reproducibility
Always
Fix