Dust HTLCs on closed channels are always retryable #1653
Milestone
Comments
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Sep 2, 2022
Previously, we wouldn't mark a dust HTLC as permanently resolved if the commitment transaction went on chain. This resulted in us always considering the HTLC as pending on restart, when we load the pending payments set from the monitors. Fixes lightningdevkit#1653.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Sep 6, 2022
Previously, we wouldn't mark a dust HTLC as permanently resolved if the commitment transaction went on chain. This resulted in us always considering the HTLC as pending on restart, when we load the pending payments set from the monitors. Fixes lightningdevkit#1653.
optout21
pushed a commit
to optout21/rust-lightning
that referenced
this issue
Jul 24, 2023
Previously, we wouldn't mark a dust HTLC as permanently resolved if the commitment transaction went on chain. This resulted in us always considering the HTLC as pending on restart, when we load the pending payments set from the monitors. Fixes lightningdevkit#1653.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At #1495 (comment) @wpaulino pointed out that we don't push
IrrevocablyResolvedHTLCs onto our resolution list for dust HTLCs. This, however, results in dust HTLCs which are a part of an outbound payment being retryable on restart after they resolve as they are always included in theget_pending_outbound_htlcsreturn value. This isn't exactly likely, but it is theoretically possible that a user sends a dust-HTLC-payment, the channel closes, after the commitment transaction has reached six blocks the user retries the payment, which completes, then the user restarts and retries the payment again, which LDK will allow them to do because it loads the payment info back from the monitor.The text was updated successfully, but these errors were encountered: