Fail HTLC backwards before upstream claims on-chain #3556
Conversation
In a coming commit we'll expire HTLCs backwards even if we haven't yet claimed them on-chain based on their inbound edge being close to causing a channel force-closure. Here we track the incoming edge's CLTV expiry in the pending-routing state so that we can include it in the `HTLCSource` in the next commit. Co-authored-by: Matt Corallo <[email protected]>
In a coming commit we'll expire HTLCs backwards even if we haven't yet claimed them on-chain based on their inbound edge being close to causing a channel force-closure. Here we track and expose the incoming edge's CLTV expiry in the `HTLCSource`, giving `ChannelMonitor` access to it. Co-authored-by: Matt Corallo <[email protected]>
This field was used to test that any HTLC failures didn't come in after an HTLC was fulfilled (indicating, somewhat dubiously, that there may be a bug causing us to fail when we shouldn't have). In the next commit, we'll be failing HTLCs based on on-chain HTLC expiry, but may ultimately receive the preimage thereafter. This would make the `historical_inbound_htlc_fulfills` checks potentially-brittle, so we just remove them as they have dubious value.
Fail inbound HTLCs if they expire within a certain number of blocks from the current height. If we haven't seen the preimage for an HTLC by the time the previous hop's timeout expires, we've lost that HTLC, so we might as well fail it back instead of having our counterparty force-close the channel. Co-authored-by: Matt Corallo <[email protected]>
If we've signed the latest holder tx (i.e. we've force-closed and broadcasted our state), there's not much reason to accept counterparty-transaction-updating `ChannelMonitorUpdate`s, we should make sure the `ChannelManager` fails the channel as soon as possible. This standardizes the failure cases to also match those added to the previous commit, which makes things a bit more readable.
| continue; | ||
| } | ||
| if !duplicate_event { | ||
| log_error!(logger, "Failing back HTLC {} upstream to preserve the \ |
There was a problem hiding this comment.
Nit: is this really considered an error? Info/warn seems better suited.
There was a problem hiding this comment.
Its an error in that a violation of our assumptions around tx confirmation time happened, and its probably an important enough case that users should see it and think hard about what is happening.
| mine_transaction(&nodes[1], &node_1_txn[1]); // HTLC timeout | ||
| connect_blocks(&nodes[1], ANTI_REORG_DELAY); | ||
| // Expect handling another fail back event, but the HTLC is already gone | ||
| expect_pending_htlcs_forwardable_and_htlc_handling_failed!(nodes[1], |
There was a problem hiding this comment.
We could avoid having this duplicate go out if we check the set on the confirmed timeout path, but I guess it's not worth doing since a restart in between would yield it anyway.
There was a problem hiding this comment.
I also spent a while trying to move the event generation to where we do the actual failure so that we could detect the duplicate in ChannelManager, but the changeset kinda blew up on me :/. And, yea, this should be a really rare/never kinda case, so duplicate handling-failed events skewing users' forwarding statistics is probably not the end of the world.
|
Backported in #3567 |
This rebases and replaces #2457. It removes the config option, as once we've lost the HTLC in question, not failing back to get three additional blocks of room to claim the inbound edge (after at least 39 blocks have already passed) doesn't seem like a reasonable tradeoff in nearly any case (and I'd like to reduce the 3 number to 2 anyway). It also cleans up
channela bit more by removinghistorical_inbound_htlc_fulfillsentirely, usesSentHTLCId(resolving an issue where two inbound channels have relayed two different HTLCs with the same HTLC ID into a channel causing confusion), and a few other cleanups.I'd like to backport this to 0.1 because its important for future feerate spikes.