-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Comments
@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 👍 |
Oh that's a very recent discussion, thanks for pointing me there. I agree, that also sounds like a decent fix! |
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.
The text was updated successfully, but these errors were encountered: