-
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]: lnd should allow HTLC receiver to dip into its channel reserve #8249
Comments
I think this will be covered in #8096, where we intorduce the feebuffer, but I am not sure whether we should allow going below the reserve because with the feebuffer its very unlikely to happen anyways. |
Good, that will ensure future channel won't end up stuck. But that doesn't help unblock existing channels (until the feerate decreases and an
As a receiver you should always allow it, you are 100% benefiting from this if your peer lets you go below your reserve. I don't see any reason to disallow it (that's why the spec does not tell you to disallow it).
I think you're assuming that you perform those checks when sending/receiving In eclair, we simply do the following:
|
#8096 introduced the feebuffer, but allowing the remote side to dip us below channelreserve and vice versa will be done in the follow-up PR. |
Thanks! |
Since the recent on-chain fees spike, we've noticed that many of our lnd peers increased the commit tx feerate to the point where they are just above their channel reserve, without keeping a buffer for the increased commit tx fees for an incoming HTLC. Those channels are thus stuck, because of the very old issue described in lightning/bolts#740
Since we implemented splicing in eclair, we realized that the receiver of an HTLC should always accept incoming HTLCs that make the receiver temporarily drop below their reserve (because of the increased commit tx fees). It is the sender that is taking a risk by doing so. The spec does not tell receivers to treat this as an error, but lnd (and cln) do. This is very annoying, because we could unblock those channels if lnd accepted incoming HTLCs in that situation. Could you relax that requirement instead of sending an
invalid update
error?The text was updated successfully, but these errors were encountered: