Skip to content

[bug]: stale commitment fee for rarely active channels #8790

@rkfg

Description

@rkfg

Background

Commitment fee (CFee) may get very stale after a while for the private (unpublished) channels if the peer isn't online for a while. I have a few such private channels to my own various wallets and also a channel to my friend. He only uses it rarely to receive payments and exits the app right after that. I initiated this channel so only I can update the CFee. However, it was once set to 1 sat/vB and never updated since. This issue applies mostly to the private channels because they're assumed to be inactive most of the time. Public channels are used for routing and must always be active so the update will happen sooner or later.

I did a little research and it seems that CFee only updates (links point to the relevant source line) when a channel timer elapses but never for any other reason. The timer has a random period between 10 and 60 minutes, it can not be changed by the user I assume, couldn't find any relevant code and config parameters. So the clients that don't stay online for quite a long while (up to 1 hour) will never receive a fee update. They may get stuck with a very low fee until they have to FC (due to their LSP losing the state/shutting down/the LSP decides to FC instead) only to find out that their FC tx can't even enter the mempool because it's below the purge level.

AFAIK no apps show the current CFee so the problem would be quite hidden. I see it in lntop and I can also check it with lncli listchannels of course. But the mobile clients either have it buried in the dev settings or don't expose it at all. Asking the peer to keep their phone on with the app active for up to 1 hour (I don't know what period the timer has, it's random) so that their balance can actually be resolved on chain if things go south, is an extremely bad UX. Also CFee can not be forcibly updated by the lnd user. The only way is that single timer, I didn't find any other lines that call this function.

Your environment

  • version of lnd v0.17.5
  • which operating system (uname -a on *Nix) 6.1.0-21-amd64 Fix name typo in README #1 SMP PREEMPT_DYNAMIC (Debian 12.5 stable)
  • version of btcd, bitcoind, or other backend v26.1.knots20240325
  • any other relevant environment details

Steps to reproduce

  1. Open a private channel, can be public as well, it shouldn't matter; for mobile apps I usually open a private one
  2. Wait for the fees to be low enough, keep the app running so the CFee is updated
  3. Exit the app, wait for the fees to rise
  4. Open the app, do any payments, close it in under 10 minutes
  5. Keep doing it from time to time and your CFee will stay low

Expected behaviour

I have two ideas:

  1. When a channel becomes active check if more than DefaultMaxLinkFeeUpdateTimeout passed since the last fee update. If yes, do a fee update.
  2. Also do it after every settled HTLC.

Now, both ideas assume that we can (we're the initiator) and should (fees changed by a lot) do a fee update. Otherwise it's a NOP.

Metadata

Metadata

Assignees

Labels

P2should be fixed if one has timechannelsfeature requestRequests for new featuresmobileneutrinoLightweight neutrino backend-type

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions