Fail HTLCs which were removed from a channel but not persisted#1857
Merged
TheBlueMatt merged 3 commits intolightningdevkit:mainfrom Dec 5, 2022
Merged
Fail HTLCs which were removed from a channel but not persisted#1857TheBlueMatt merged 3 commits intolightningdevkit:mainfrom
TheBlueMatt merged 3 commits intolightningdevkit:mainfrom
Conversation
TheBlueMatt
force-pushed
the
2022-11-reload-htlc
branch
2 times, most recently
from
5180e9e to
d793bb8
Compare
Codecov ReportBase: 90.60% // Head: 91.78% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1857 +/- ##
==========================================
+ Coverage 90.60% 91.78% +1.17%
==========================================
Files 91 91
Lines 47969 56197 +8228
Branches 47969 56197 +8228
==========================================
+ Hits 43463 51581 +8118
- Misses 4506 4616 +110
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
TheBlueMatt
force-pushed
the
2022-11-reload-htlc
branch
from
d793bb8 to
227a8bd
Compare
Contributor
|
Needs rebase |
TheBlueMatt
force-pushed
the
2022-11-reload-htlc
branch
from
227a8bd to
f9f1f81
Compare
Collaborator
Author
|
Rebased. |
TheBlueMatt
force-pushed
the
2022-11-reload-htlc
branch
from
f9f1f81 to
d17ce49
Compare
dunxen
reviewed
Nov 29, 2022
Contributor
dunxen
left a comment
dunxen
left a comment
There was a problem hiding this comment.
LGTM AFAICT. Just nits. One optional.
TheBlueMatt
force-pushed
the
2022-11-reload-htlc
branch
from
d17ce49 to
3149544
Compare
dunxen
previously approved these changes
Dec 5, 2022
This expands the outbound-HTLC-listing support in `ChannelMonitor` to include not only the set of outbound HTLCs which have not yet been resolved but to also include the full set of HTLCs which the `ChannelMonitor` is currently able to to or has already finalized. This will be used in the next commit to fail-back HTLCs which were removed from a channel in the ChannelMonitor but not in a Channel. Using the existing `get_pending_outbound_htlcs` for this purpose is subtly broken - if the channel is already closed, an HTLC fail may have completed on chain and is no longer "pending" to the monitor, but the fail event is still in the monitor waiting to be handed back to the `ChannelMonitor` when polled.
If, after forwarding a payment to our counterparty, we restart with a ChannelMonitor update having been persisted, but the corresponding ChannelManager update was not persisted, we'll still have the forwarded HTLC in the `forward_htlcs` map on start. This will cause us to generate a (spurious) `PendingHTLCsForwardable` event. However, when we go to forward said HTLC, we'll notice the channel has been closed and leave it up to the `ChannelMontior` to finalize the HTLC. This is all fine today - we won't lose any funds, we'll just generate an excess forwardable event and then fail to forward. However, in the future when we allow for forward-time channel changes this could break. Thus, its worth adding tests for this behavior today, and, while we're at it, removing the spurious forwardable HTLCs event.
When a channel is force-closed, if a `ChannelMonitor` update is completed but a `ChannelManager` persist has not yet happened, HTLCs which were removed in the latest (persisted) `ChannelMonitor` update will not be failed even though they do not appear in the commitment transaction which went on chain. This is because the `ChannelManager` thinks the `ChannelMonitor` is responsible for them (as it is stale), but the `ChannelMonitor` has no knowledge of the HTLC at all (as it is not stale). The fix for this is relatively simple - we need to check for this specific case and fail back such HTLCs when deserializing a `ChannelManager`
TheBlueMatt
force-pushed
the
2022-11-reload-htlc
branch
from
3149544 to
dbe4aad
Compare
Collaborator
Author
|
Squashed fixups. |
dunxen
approved these changes
Dec 5, 2022
wpaulino
approved these changes
Dec 5, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on #1830 (I didn't pull it all in, but there's one commit that just takes one function from there).When a channel is force-closed, if a
ChannelMonitorupdate iscompleted but a
ChannelManagerpersist has not yet happened,HTLCs which were removed in the latest (persisted)
ChannelMonitorupdate will not be failed even though they do not appear in the
commitment transaction which went on chain. This is because the
ChannelManagerthinks theChannelMonitoris responsible forthem (as it is stale), but the
ChannelMonitorhas no knowledge ofthe HTLC at all (as it is not stale).
The fix for this is relatively simple - we need to check for this
specific case and fail back such HTLCs when deserializing a
ChannelManager