Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug]: implement "fee spike buffer" from spec #7721

Closed
C-Otto opened this issue May 23, 2023 · 2 comments · Fixed by #8096
Closed

[bug]: implement "fee spike buffer" from spec #7721

C-Otto opened this issue May 23, 2023 · 2 comments · Fixed by #8096
Labels

Comments

@C-Otto
Copy link
Contributor

C-Otto commented May 23, 2023

A channel initialized by the local node can only receive funds if the local balance is high enough to pay additional on-chain fees for the added (incoming) HTLC in case we need to go on-chain (force close). If the local balance is too low (which can also happen if the on-chain fees rise), the channel is rather unusable: only dust amounts can be received until the local balance is high enough.

In this "low balance" situation, lnd complains when sending to a peer that initiated the channel. If the balance on the peer's side is too low, the local lnd does not allow forwarding of non-dust amounts:

[INF] LNWL: ChannelPoint(xxx:0): Reducing local balance (from 29xxxxxxxx mSAT to 353999 mSAT): remote side does not have enough funds (3510xxx mSAT < 3571000 mSAT) to pay for non-dust HTLC in case of unilateral close.

(In this example the peer only has 3,510 sat on their side, which is below the current threshold of 3,571 sat. Because of this, a forward of 2.9 million sat did not happen)

See #7108 and lightning/bolts#728 for a discussion of this. The solution according to lightning/bolts#740 is to implement a "fee spike buffer" so that nodes don't deplete their balance if this reduction could cause the channel to be unusable.

See #7717 for a mitigation idea.

@ellemouton
Copy link
Collaborator

ellemouton commented May 23, 2023

@C-Otto - what do you think of just allowing the payment even if it goes below the initiators reserve as described here: lightning/bolts#1083

EDIT: this can ofc only be done once the receiver stops erroring here... otherwise they would force close. So perhaps an intermediate solution like you suggest would be a good idea 👍

@C-Otto
Copy link
Contributor Author

C-Otto commented May 23, 2023

Oh that's a very recent discussion, thanks for pointing me there. I agree, that also sounds like a decent fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants