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

Support claiming from closed channels #2017

Closed
TheBlueMatt opened this issue Feb 6, 2023 · 1 comment · Fixed by #2148
Closed

Support claiming from closed channels #2017

TheBlueMatt opened this issue Feb 6, 2023 · 1 comment · Fixed by #2148
Milestone

Comments

@TheBlueMatt
Copy link
Collaborator

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.

@TheBlueMatt
Copy link
Collaborator Author

TheBlueMatt commented Mar 23, 2023

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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant