-
Notifications
You must be signed in to change notification settings - Fork 367
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
Support claiming from closed channels #2017
Milestone
Comments
Note see above mention in comment thread, probably need to bump the buffer when accepting an HTLC vs timing it out. |
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Apr 4, 2023
Previously, LDK would refuse to claim a payment if a channel on which the payment was received had been closed between when the HTLC was received and when we went to claim it. This makes sense in the payment case - why pay an on-chain fee to claim the HTLC when presumably the sender may retry later. Long ago it also reduced total code in the claim pipeline. However, this doesn't make sense if you're trying to do an atomic swap or some other protocol that requires atomicity with some other action - if your money got claimed elsewhere you need to be able to claim the HTLC in lightning no matter what. Further, this is an over-optimization - there should be a very, very low likelihood that a channel closes between when we receive the last HTLC for a payment and the user goes to claim the payment. Since we now have code to handle this anyway we should allow it. Fixes lightningdevkit#2017.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Apr 4, 2023
Previously, LDK would refuse to claim a payment if a channel on which the payment was received had been closed between when the HTLC was received and when we went to claim it. This makes sense in the payment case - why pay an on-chain fee to claim the HTLC when presumably the sender may retry later. Long ago it also reduced total code in the claim pipeline. However, this doesn't make sense if you're trying to do an atomic swap or some other protocol that requires atomicity with some other action - if your money got claimed elsewhere you need to be able to claim the HTLC in lightning no matter what. Further, this is an over-optimization - there should be a very, very low likelihood that a channel closes between when we receive the last HTLC for a payment and the user goes to claim the payment. Since we now have code to handle this anyway we should allow it. Fixes lightningdevkit#2017.
optout21
pushed a commit
to optout21/rust-lightning
that referenced
this issue
Jul 24, 2023
Previously, LDK would refuse to claim a payment if a channel on which the payment was received had been closed between when the HTLC was received and when we went to claim it. This makes sense in the payment case - why pay an on-chain fee to claim the HTLC when presumably the sender may retry later. Long ago it also reduced total code in the claim pipeline. However, this doesn't make sense if you're trying to do an atomic swap or some other protocol that requires atomicity with some other action - if your money got claimed elsewhere you need to be able to claim the HTLC in lightning no matter what. Further, this is an over-optimization - there should be a very, very low likelihood that a channel closes between when we receive the last HTLC for a payment and the user goes to claim the payment. Since we now have code to handle this anyway we should allow it. Fixes lightningdevkit#2017.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In general, if you're just accepting payment, you shouldn't want to claim HTLCs from channels that already went on-chain - just let the sender retry and make your counterparty pay the on-chain fee rather than us. However, there are some cases where you need to - if you are claiming the HTLC as a part of an on-chain swap, or otherwise forwarded a payment onwards without using the built-in forwarding utilities. Really people probably shoulnd't be doing those things - forwarding should forward the onion for many reasons, swaps should have the on-chain tx go first and then do the lightning bit to avoid channel jamming by accident, but users are probably going to do this anyway, so if we don't support it they'll be annoyed they lost money.
Probably we want this to be a separate claim method, cause normal claims don't want to do this, but we should support it explicitly.
The text was updated successfully, but these errors were encountered: